[Freeform-dev] [Freeform-help] Security Hole in Freeform Database Access (take 2)

[Brian Szymanski]

Take 2 of the db access security hole.

Synopsis:
Rats.,.. As Arc was kind enough to point out, the "fix" of having
config.py is not enough. So, a new patch has been backported to the imc's
on zero.bandwidthcoop.org, and is applied in CVS. This time we actually
catch the exception thrown, which we probably should be doing anyway, so
we can output a happy little "sorry, sql database is down, try again
later" message. The error in place should probably be more user-friendly,
feel free to improve it.
Sorry for the misfire yesterday.

Exploit:
None, really, unless you have localhost db access.

Greetz:
Just kidding.

Peace,
Brian Szymanski
address@hidden

> Hi all,
>
> The bottom line is, don't worry, it's not a big deal, and it's been
> fixed in the CVS since 2002/07/25 11:59:54 UTC, and imc_ithaca,
> imc_rochester, imc_rosario, and imc_cfl have all had patches manually
> applied to the same effect.
> Summary:
> All versions of freeform checked out before 2002/07/25 11:59:54 UTC
> (specifically, including funct.py v1.5 or lower according to CVS
> version numbering) are vulnerable to the following problem. Upgrading
> should be a high priority for all affected installations.
> Description:
> If there is any other error connecting to the database (transient net
> problems, overloaded server, etc.). The cgi traceback will include
> something like:  Error at line 27 (plus or minus, depending on the
> revision of the code):
>  return
>  MySQLdb.connect('sqlmachine','sql_user','password','sql_imc_db')
> That is, the sql username and password will be output cleartext to
> anyone connecting to the server at while the sql error persists.
> Since version 1.5 of funct.py, conf.py.sample has been included for
> ease of administration, instead of dummy
> username/password/sqldbhost/sqldbtable pairs in the code. That is, now
> if the sql server is down, the error message is more benign:  Error at
> line 27 (plus or minus, depending on the revision of the code):
>  return MySQLdb.connect(sqlmachine,sql_user,password,sql_imc_db)
> Note the lack of quotes - that is the actual machine/user/password are
> not output, only the variable names, which in themselves reveal
> nothing. The moral of the story, the way I see it, is that since python
> is an interpreted language, putting configuration info in any python
> file is a precarious bet. As is, a one letter typo in your config.py
> could reveal the imc's password to a malicious user (if it is a python
> syntax error, e.g. an extra space, or a missing '=') in config.py.
> However, there is a high overhead associated with reading a file in
> manually. Perhaps setup.py should do a sanity check on config.py to
> make sure it is valid (ie try to import it and concatenate all the
> strings together or something - actually trying to import it should be
> enough).
> Workaround:
> 1 - Upgrade to freeform -current, although technically any checkout
> after 2002/07/25 11:59:54 UTC will be okay. (Arc, can you recommend a
> relatively stable checkout date?)2 - (The following should only be used
> as a temporary workaround, and probably left in place because it is
> just a good idea security-wise) Only allow access to your sql server
> from machines that need it using
> firewalling and/or tcpwrappers.
> Imc_ithaca, imc_rosario, imc_cfl, and imc_rochester have been patched
> for this bug (after a full backup was made) as of 9/17/2002 @2:30AM
> US/Eastern time. Arc, do a ls and diff in the folder to see the
> (trivial) fix I applied to the problem.
> Peace,
> Brian Szymanski
> address@hidden
>
>
>
>
>
> _______________________________________________
> Freeform-help mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/freeform-help