Neil Schemenauer wrote:

M.-A. Lemburg wrote:

...

Note that the version in Python does not result in *stack* overflows which are the type of buffer overflow usually used in exploits. ... The only attack on this kind of emulation is a denial of service attack.

That is a bold statement to make. It is also not true. Heap overflows _can_ be exploited to execute arbitrary code. I believe there was a phrack article a few years ago on the subject.

I know that they can be exploited (should have phrased the reply more carefully), but I don't think that the exploits described in phrack apply to Python's use of the memory buffer. In case sprintf() overflows, Python will detect this and immediately dump core. I don't see how this could be used by an attacker, except for killing off processes (the DOS attack); the exploit described in Phrack 57 (http://www.phrack.org/) only works on systems which use Doug Lea's malloc implementation, don't define snprintf() in their C lib and have sudo installed. Should be a rather small share of installed OSes ;-)

...

In the 3 cases where this API is used in Python, an overflow is not possible (unless the native sprintf() implementation is broken).

That may be the case today but I'm sure that snprintf will start getting more use now that it is available. We really should have a better implementation than mysnprintf.

No objection at all -- I wrote the emulation simply to add at least some level of protection against buffer overflows for platforms which don't provide snprintf() in their own C lib. Before that Python used sprintf(). I suppose we could use the code from stringobject.c:PyString_FromFormatV() as starting point for our own little snprintf() implementation... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

Grepping through the Python source code there are 191 usages of sprintf() -- shouldn't these be modified to use PyOS_snprintf() instead ? Python/getargs.c would be a particularly important case to fix, since the sprintf()s in there are not protected against buffer overflows -- it seems that long function names could be used to exploit this, e.g. in multi-user environments like Zope to obtain admin priviledges. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

"Martin v. Loewis" wrote:

...

Grepping through the Python source code there are 191 usages of sprintf() -- shouldn't these be modified to use PyOS_snprintf() instead ?

Not necessarily. sprintf is perfectly ok if used correctly (i.e. if you can guarantee an upper bound on the resulting string length, and compute this bound either statically or dynamically).

This is done in most cases, indeed. Still I think we need some auditing here and having all audited sprintf() uses renamed to say PyOS_snprintf() would make auditing future Python releases a lot easier.

...

Python/getargs.c would be a particularly important case to fix, since the sprintf()s in there are not protected against buffer overflows -- it seems that long function names could be used to exploit this, e.g. in multi-user environments like Zope to obtain admin priviledges.

That indeed appears to be the case. However, given

char buf[256]; sprintf(p, "%s() ", fname);

I think the correct reformulation should be

char buf[256]; sprintf(p, "%.100s() ", fname);

Right.

In seterror, you add then a number of strings containing each a %d (adding 20 bytes worst-case each), where the loop should terminate if there are only, say, 140 bytes left; the final printf could then use %.100s.

Alternatively, you could use "%.*s" through-out, operating with the lengths of the strings themselves.

I think that would make the code much more complicated. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/