full-disclosure - Re: Python 2.5 (Modules/zlib) minigzip local buffer overflow vulnerability

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <200703151710.18895.ismail@pardus.org.tr>
Date: Thu, 15 Mar 2007 17:10:18 +0200
From: Ismail Dönmez <ismail@...dus.org.tr>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Python 2.5 (Modules/zlib) minigzip local
	buffer overflow vulnerability

On Thursday 15 March 2007 16:48:55 you wrote:
> On Thu, 15 Mar 2007 14:16:41 +0200, Ismail =?utf-8?q?D=C3=B6nmez?= said:
> > str{cpy,cat,...} which don't take an size attribute should be removed
> > from standard libc, I don't see why people still insist on using this
> > insecure variants.
>
> Although it may come as a surprise to some, not all software has to worry
> about working in a security-critical environment.  Quite often, the program
> is a one-off that's working with data that is relatively trustable, and
> there is little or no chance of the software being compromised.  And keep
> in mind that str* functions *can* be used safely if somebody did a strlen()
> check earlier in the program.

Ok well still you can't predict the future, the product might some use 
elsewhere in a different environment. Using strncpy is just strcpy + strlen 
anyway it can't have a big speed impact or anything.

> I mean, come *ON*.  If there exists a black hat that can drop an exploit
> string into the middle of a data file produced by some data-mining program
> of ours, and exploit a program that *didn't even exist* when the data was
> written.....  in that case, we're screwed anyhow.  There's no way to stop
> a black hat that knows how to exploit code from the future.

Nothing is truly secure, that doesn't mean we should write known-to-be 
insecure code now does it? :)

-- 
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)

Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/