From tom at electric-sheep.org Wed May 14 02:00:45 2008 From: tom at electric-sheep.org (Thomas) Date: Wed, 14 May 2008 11:00:45 +0200 Subject: [splint-discuss] detecting infinite loops Message-ID: <200805141100.46012.tom@electric-sheep.org> Hello, I attached a C source-code file with 6 loops (a-f). Description of the loops: a: infinite, i is not modified b: infinite, i is not modified c: finite, 10 to 1 d: infinite, starts from 10 e: infinite, u is unsigned and can not be < 0, integer wrap-around will happen f: infinite, i tested, u modified splint detection: a: correct: endless_loops.c:9:8: Suspected infinite loop. No value used in loop test (i) is modified by test or loop body. This appears to be an infinite loop. Nothing in the body of the loop or the loop test modifies the value of the loop test. Perhaps the specification of a function called in the loop body is missing a modification. (Use -infloops to inhibit warning) b: correct: endless_loops.c:15:8: Suspected infinite loop. No value used in loop test (i) is modified by test or loop body. This appears to be an infinite loop. Nothing in the body of the loop or the loop test modifies the value of the loop test. Perhaps the specification of a function called in the loop body is missing a modification. (Use -infloops to inhibit warning) c: correct: finite loop, nothing special here d: incorrect: nothing detected here, only the printf() is mentioned e: partly correct: endless_loops.c:35:14: Comparison of unsigned value involving zero: u < 0 An unsigned value is used in a comparison with zero in a way that is either a bug or confusing. (Use -unsignedcompare to inhibit warning) f: incorrect: nothing detected here, only the printf() is mentioned Loop (d) and (f) can be detected easily I think but they are not. For (e) the comparsion "u < 0" is mentioned correctly but the infinite loop that results from it is not mentioned. This is a problem if "-unsignedcompare" is used on the command line, then the code line is not reported anymore. Are these kind of infinite loops not supported by splint or did I miss a flag/annotation? Thanks. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: endless_loops.c Type: text/x-csrc Size: 416 bytes Desc: not available Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080514/269c15d5/attachment.bin From tom at electric-sheep.org Wed May 14 07:33:18 2008 From: tom at electric-sheep.org (Thomas) Date: Wed, 14 May 2008 16:33:18 +0200 Subject: [splint-discuss] detecting buffer overflows Message-ID: <200805141633.19926.tom@electric-sheep.org> Hello everybody, I attached a file with different C functions that cause an overflow (or not). I was wondering a bit about the detection of the vulnerable code. a: detected bof_static.c:12:2: Likely out-of-bounds store: a[5] bof_static.c:13:2: Likely out-of-bounds store: b[10] b: *not* detected no complains about the off-by-one c: detected bof_static.c:20:2: Possible out-of-bounds store: strcpy(a, b) d,e,g,h,i: *not* detected no warning about the overflow (1 and 2 bytes) f,j: detected here the overflows are detected, too late k: detected bof_static.c:55:3: Possible out-of-bounds store: b[i] l: not detected this one is only detected if (k) is not in the code In the case of (l), why is no warning displayed? Are the constraints for memset(), memcpy(), strncpy() not correct? Bye Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: bof_static.c Type: text/x-csrc Size: 1057 bytes Desc: not available Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080514/5beef11c/attachment.bin From splint at sympatico.ca Wed May 14 19:07:37 2008 From: splint at sympatico.ca (Bill Pringlemeir) Date: Wed, 14 May 2008 22:07:37 -0400 Subject: [splint-discuss] detecting buffer overflows In-Reply-To: <200805141633.19926.tom@electric-sheep.org> (Thomas's message of "Wed\, 14 May 2008 16\:33\:18 +0200") References: <200805141633.19926.tom@electric-sheep.org> Message-ID: Try this command, "splint +strict bof_static.c". Some of the detections that you might think are easy can do the following, 1) Introduce many false positives. 2) Require a lot of CPU power to track values. 3) Add little value to realistic code samples. The strict mode has the highest use of CPU and also introduces the most false positives. Choosing errors to track is an art. You wish to minimize false positives, not take exhorbitant CPU time and catch the majority of common programming errors. I think with +strict many of the errors are flagged. There is also '+strictposixlib' (or some such) which might have more stringent standard library annotations. Finally, I am not quite sure if some of your loops are infinite. A good warning might be "loop terminates after overflow" for some of them. fwiw, Bill Pringlemeir. On 14 May 2008, tom at electric-sheep.org wrote: > Hello everybody, I attached a file with different C functions that > cause an overflow (or not). > > I was wondering a bit about the detection of the vulnerable code. > > a: detected > bof_static.c:12:2: Likely out-of-bounds store: a[5] > bof_static.c:13:2: Likely out-of-bounds store: b[10] > > b: *not* detected > no complains about the off-by-one > > c: detected > bof_static.c:20:2: Possible out-of-bounds store: strcpy(a, b) > > d,e,g,h,i: *not* detected > no warning about the overflow (1 and 2 bytes) > > f,j: detected > here the overflows are detected, too late > > k: detected > bof_static.c:55:3: Possible out-of-bounds store: b[i] > > l: not detected > this one is only detected if (k) is not in the code > > > In the case of (l), why is no warning displayed? > > Are the constraints for memset(), memcpy(), strncpy() not correct? > > > Bye > Thomas > > > _______________________________________________ > splint-discuss mailing list > splint-discuss at mail.cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/splint-discuss -- Keep an open mind. But not so open your brains fall out. - Kallis' Law From tom at electric-sheep.org Thu May 15 03:12:02 2008 From: tom at electric-sheep.org (Thomas) Date: Thu, 15 May 2008 12:12:02 +0200 Subject: [splint-discuss] not all warnings displayed Message-ID: <200805151212.02906.tom@electric-sheep.org> Hi, what is the reason that splint does not print warnings for all possible bugs in the code? For example if I have a flawed strcpy() followed by a flawed memcpy() only the strcpy is displayed but not the memcpy(). The memcpy is only displayed after I removed the strcpy-case. Thanks Thomas From tom at electric-sheep.org Thu May 15 04:50:32 2008 From: tom at electric-sheep.org (Thomas) Date: Thu, 15 May 2008 13:50:32 +0200 Subject: [splint-discuss] question about constraints, missing warning Message-ID: <200805151350.33267.tom@electric-sheep.org> Hi. I have a problem with understanding constraints, or it's abug: For example memcpy(): void *memcpy ( /*@unique@*/ /*@out@*/ /*@returned@*/ void *dest, const void *src, size_t n ) /*@modifies *dest@*/ /*@requires maxSet(dest) >= (n-1); @*/ /*@ensures maxRead(src) >= maxRead(dest) /\ maxRead(dest) <= n;@*/; Code example: char a[5]; char b[10]; // h memcpy(a, b, sizeof(a)+1); printf("sink: %s\na: %s\nb: %s\n\n", sink, a, b); // i memcpy(a, b, sizeof(a)+2); printf("sink: %s\na: %s\nb: %s\n\n", sink, a, b); Splint only reports: bof_static.c:62:2: Likely out-of-bounds store: memcpy(a, b, sizeof((a)) + 2) But not the off-by-one of case (h). Why that? When I resolve the constraint I get: maxSet(a) = 4 n = sizeof(a) + 1 = 6 n-1 = 6 - 1 = 5 4 >= 5 ==> FALSE splint should warn about this, shouldn't it? Bye Thomas From tom at electric-sheep.org Thu May 15 04:55:00 2008 From: tom at electric-sheep.org (Thomas) Date: Thu, 15 May 2008 13:55:00 +0200 Subject: [splint-discuss] detecting buffer overflows In-Reply-To: References: <200805141633.19926.tom@electric-sheep.org> Message-ID: <200805151355.01913.tom@electric-sheep.org> Am Donnerstag, 15. Mai 2008 schrieb Bill Pringlemeir: > > Try this command, "splint +strict bof_static.c". Some of the > detections that you might think are easy can do the following, Unfortunately it does not report less false negatives. > 1) Introduce many false positives. Yes, it shows really strange messages, like printf() modifying the file system state. > 3) Add little value to realistic code samples. Some new warnings are really interesting. For example if a parameter of type size_t of calloc() is a variable of type int. Very realistic problem to spot exploitable heap overflows due to integer overflow / sign issues. > I think with +strict many of the errors are flagged. There is also > '+strictposixlib' (or some such) which might have more stringent > standard library annotations. Hm, doesn't help. > Finally, I am not quite sure if some of your loops are infinite. A > good warning might be "loop terminates after overflow" for some of > them. How can this be enabled? And what kind of overflow? > fwiw, > Bill Pringlemeir. Bye Thomas From jon.wilson at globalgraphics.com Thu May 15 07:02:54 2008 From: jon.wilson at globalgraphics.com (Jon Wilson) Date: Thu, 15 May 2008 15:02:54 +0100 Subject: [splint-discuss] detecting buffer overflows In-Reply-To: <200805151355.01913.tom@electric-sheep.org> References: <200805141633.19926.tom@electric-sheep.org> <200805151355.01913.tom@electric-sheep.org> Message-ID: <482C428E.4070500@globalgraphics.com> Thomas wrote: > Am Donnerstag, 15. Mai 2008 schrieb Bill Pringlemeir: >> Finally, I am not quite sure if some of your loops are infinite. A >> good warning might be "loop terminates after overflow" for some of >> them. > > How can this be enabled? And what kind of overflow? For example, your case "d": // d for(i = 10; i > 0; i++) { printf("%x.", i); } is not an infinite loop as you intimate. It _will_ terminate because i will go negative, but only after it overflows: a b c d e f 10 11 12 13 . . . . . . . 7ffffff6 7ffffff7 7ffffff8 7ffffff9 7ffffffa 7ffffffb 7ffffffc 7ffffffd 7ffffffe 7fffffff As far as I know, Splint doesn't currently have such a warning - but then does any other static checking tool I've used. Jon >> fwiw, >> Bill Pringlemeir. > > Bye > Thomas > > _______________________________________________ > splint-discuss mailing list > splint-discuss at mail.cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/splint-discuss From tom at electric-sheep.org Thu May 15 23:29:16 2008 From: tom at electric-sheep.org (Thomas) Date: Fri, 16 May 2008 08:29:16 +0200 Subject: [splint-discuss] detecting buffer overflows In-Reply-To: <482C428E.4070500@globalgraphics.com> References: <200805141633.19926.tom@electric-sheep.org> <200805151355.01913.tom@electric-sheep.org> <482C428E.4070500@globalgraphics.com> Message-ID: <200805160829.17761.tom@electric-sheep.org> Am Donnerstag, 15. Mai 2008 schrieb Jon Wilson: > Thomas wrote: > > Am Donnerstag, 15. Mai 2008 schrieb Bill Pringlemeir: > >> Finally, I am not quite sure if some of your loops are infinite. A > >> good warning might be "loop terminates after overflow" for some of > >> them. > > > > How can this be enabled? And what kind of overflow? > > For example, your case "d": > > // d > for(i = 10; i > 0; i++) > { > printf("%x.", i); > } > > is not an infinite loop as you intimate. It _will_ terminate because i > will go negative, but only after it overflows: Ah, I missed that integer overflow. But for signed integers the C99 standard does not define a behavior and it depends on the compiler's implementation what will happen. The compiler can also choose to not increase the variable anymore when it reaches INT_MAX and the loop will be infinite, splint does not know anything about the compiler or the machine code created by it. Bye Thomas From aaron.davies at gmail.com Tue May 27 14:41:09 2008 From: aaron.davies at gmail.com (Aaron Davies) Date: Tue, 27 May 2008 17:41:09 -0400 Subject: [splint-discuss] Test expressions--int allowed? Message-ID: foo.c:66:11: Test expression for conditional not boolean, type int: a Test expression type is not boolean or int. (Use -predboolint to inhibit warning) is it allowed to be int or not? i'm confused -- Aaron Davies aaron.davies at gmail.com