Python CGI security

[Moshe Zadka]

On Mon, 3 Jul 2000, Michael [iso-8859-1] Ströder wrote:

> Thomas Wouters wrote:
> > 
> > On Mon, 03 Jul 2000 08:47:47 +0200, Michael Ströder <michael at stroeder.com>
> > wrote:
> > >"E. Jordan Bojar" wrote:
> > 
> > >> [..] buffer overflow [..] 
> > 
> > >I'm not a C programmer at all and therefore I just naively used a
> > >tool named ITS4: <URL: http://www.rstcorp.com/its4/> to find parts
> > >in the Python interpreter which might have buffer overrun issues. I
> > >would really like to have some discussion about the ITS4-output.
> > 
> > If you do want to have that discussion, feel free to send me that report, 
> > or post it here
> 
> Ok, here are some examples from Python1.6a2 sources (see below). I'm
> not a C programmer therefore such tools are my only possibility to
> raise some discussion by pointing to code. Off course the tool
> outputs only hints. Not every code line listed is a real security
> hole.

OK, here is an answer to the report I just snipped.
There are a few types of "potential security holes":

 -- exposing insecure parts of the API, such as os.system(). These should
    stay, since the user should have those at his disposale

 -- OS/2 message formatting. I haven't looked at it, but this only
    concerns you if you're working on OS/2

 -- checked "dangerous" functions, which are therefore fine as far as I
    could see

 -- one sprintf() which will work fine as long as integers are <128 bits, 
    which is true in the forseeable feature. I'm planning to patch this,
    just in case, but it should be fine anyway. (I'm talking about the 
    first sprintf() in posixmodule.c)


--
Moshe Zadka <moshez at math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.