full-disclosure - The Trillian GPL violation allegations are confirmed false.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <200403020056.i220uxNu006081@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: The Trillian GPL violation allegations are confirmed false. 

On Mon, 01 Mar 2004 21:38:22 +0100, Tobias Weisserth <tobias@...sserth.de>  said:

> Abstract algorithms do not have real-world exploitable buffer overflows.
> Real-world implementations of abstract algorithms do have buffer
> overflows.

Only true because abstract algorithms aren't executable at all.

Over the past quarter century, I've seen essentially every known class of bug
included in software written to specifications because the specification
was buggy.

All it takes for the code to have a buffer overflow is for the specification to
omit the phrase "You are responsible for bounds checking", or otherwise imply
that the caller of your function has already done so.

Feel free to go take a copy of the Gaim source code, and create a pseudocode
or other specification of the function yahoo_process_auth_new() that is
sufficiently detailed so it's impossible to fail to check bounds at the right places.

> See above. Please give an example of an abstract algorithm (maybe in
> pseudo-code) that contains a real-world exploitable buffer overflow.

See above.  Abstract algorithms aren't real-world executable.

But since you asked, try googling for '+bug +pseudocode +overrun'. Here's a wonderful hit:

http://cvs.winehq.com/cvsweb/wine/dlls/cabinet/cabextract.c?rev=1.10

About halfway down, we find this gem of a comment...

/* LZX decruncher */

/* Microsoft's LZX document and their implementation of the
 * com.ms.util.cab Java package do not concur.
 *
 * In the LZX document, there is a table showing the correlation between
 * window size and the number of position slots. It states that the 1MB
 * window = 40 slots and the 2MB window = 42 slots. In the implementation,
 * 1MB = 42 slots, 2MB = 50 slots. The actual calculation is 'find the
 * first slot whose position base is equal to or more than the required
 * window size'. This would explain why other tables in the document refer
 * to 50 slots rather than 42.
 *
 * The constant NUM_PRIMARY_LENGTHS used in the decompression pseudocode
 * is not defined in the specification.

Figuring out what happens when somebody uses 42 instead of 50 is left as
an exercise for the reader....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040301/e6ba52f0/attachment.bin