I guess some would argue, but the "Writing secure code" book from MS, is pretty good. Although it doesn't directly refernce UNIX, I think it would be helpful. It contains their technique of source review, which can be adopted by you (or even partially adopted). >From: dwar keeper <dwarkeeperat_private> >To: vuln-devat_private >Subject: Research on Source Code Review -C >Date: 7 Jun 2003 15:43:55 -0000 > >In-Reply-To: <KFEMINDBKGBEMHACCJHCOEJKCNAA.brettat_private> > >Hi, > >Am looking to develop source code review guidelines for code written in >c/c++. I have found a few documents on the net but nothing that could be >really followed along to do source code review. I also wanted to know what >people in the field are actually doing and also if they could provide >first hand experience as to what all they look for and how. > >Some of the software we write also is used on different flav. of UNIX, >thus how would that impact on finding such as heap overflows (simply would >it even be a finding if the software is run on solaris as opposed to linux >where dl malloc is used and it is actually a heap overflowetc) ? I want to >try and build and exaustive list of functions and a detailed document of >what all functions, steps to look at on while performing a ssource code >review. > >I have started with a list of functions for stack already, they have been >compiled by looking at most of the pre-existing tools (Flawfinder/RATS >etc) and am also trying to classify all the different types of flaws that >could occur. I am sure there are a lot of people on this list who have a >lot more information, I want to just try to collate it all and in the end >shall try and post it to the list too so every can gain from this if >possible. > >Thanks in advance for all your help. > >/DK > >I have some examples here as to what flaws to look for please add more and >give some description or provide a link, thanks. > >A) Stack >Problem functions listed in stack_func.txt attached. > >Ways to stop stack overflows are either use other functions which validate >the input or disable stack execution ( however if return into libc is >used, this attack will still be successful for disabled stack execution so >always use validated functions or compile with safe versions of gcc). > >B) Heap >Problems that could arise in the heap due to use of contiguos blocks to >store data and the first variable overwrites data into the second block. >The overhead part of each block, which contains the address of the next >location to execute could be overwritten and thus /bin/sh could be called >or something along those lines. > >Functions that couse cause such problems are - > >Possible solutions using canary values between variables, what else could >be possible solutions? What are the possible functions on this? > > >C) Format string >locating all "F" class of functions and validating the format. > >D) Off by one > > >E) Race Condition > > >F) Dead lock > >G) Implementations of Malloc and other such tools (I found dl malloc on >phrack but other implementations on os's like aix / sun any pointers ??) > > >Additional vectors >-------------------- >1) Integer Overflow (could lead to either stack or heap overflow) - > - Evaluating the value stored in a integer (store a value greater than >the maximum value allowed in an integer variable thus causing an integer >overflow) > Fix would be to add an additional loop to check for the size of >the value > All possible scenarios they could be used under ? > >2) Signed Overflow > Signed overflows occur when a signed variable is interpreted as an >unsigned variable. > Fix using the correct ‘type’ required for the variable. > What are all the different singed variables that could be mis- >interpreted and used ? > >Thanks again for all the help. > > _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
This archive was generated by hypermail 2b30 : Thu Jun 12 2003 - 12:00:43 PDT