[<prev] [next>] [day] [month] [year] [list]
Message-ID: <5ed37b141001220959m69871d5ckab448f7073faabf3@mail.gmail.com>
Date: Fri, 22 Jan 2010 09:59:45 -0800
From: Chris Travers <chris@...atrontech.com>
To: bugtraq@...urityfocus.com
Subject: CVE-2009-3583, confirming problem and adding info
CVE-2009-3583 refers to a security vulnerability in SQL-Ledger (and
presumably some offshoots, including early versions of LedgerSMB)
whereby one can include arbitrary Perl code.
All versions of SQL-Ledger 2.x are presumed vulnerable. At least my
experience with SQL-Ledger suggests that the relevant code has not
changed significantly since at least 2.2.0.
All versions of LedgerSMB lower than 1.2.0 are vulnerable. 1.2.0 is
the first version that is not vulnerable.
Original full disclosure email at:
http://archives.neohapsis.com/archives/fulldisclosure/2009-12/0415.html
by another author.
I have not checked other offshoots.
I am writing because I don't think the original full disclosure email
provided sufficient information as to how this could be typically
exploited in a system with typical installations of SQL-Ledger or
offshoots. Indeed, when combined with standard functionality of the
software in typical configurations, the vulnerability is relatively
easy to exploit and does not require external upload access.
The problem here is that software allows one to create arbitrarily
named files in the css and templates directories through the template
editor. Since these files are not checked for sanity (and indeed
directory transversal has been an issue there too, but that is not
necessary to exploit this problem).
Hence if one creates a file myperlscript.css in the css directory
using the file editor that is built in with SQL-Ledger, one can then
execute the Perl code in that file using that vulnerability.
Typically, SQL-Ledger and LedgerSMB installations have these
directories writeable to the web server. In short, in typical
configurations, the application is vulnerable regardless of other
applications configured on the system.
Early versions of LedgerSMB are vulnerable (but they have many other
security problems too). However, in 1.2.0 we moved from perl scripts
that set up localization structures to the more standard gettext .po
format. For this reason country codes are no longer used to execute
arbitrary code.
If anyone is still using LedgerSMB 1.1.x, this is an excellent reason
to upgrade.....
I can confirm this problem for the versions mentioned.
Best Wishes,
Chris Travers
Powered by blists - more mailing lists