Hi all; A minor sql injection issue has been discovered in 1.2.x which is not believed to be exploitable. This email describes the issue, the threat assessment (why we conclude it is not a threat) as well as the rationale for providing a hotfix. Due to the nature of this issue it is not expected to pose security problems and no security advisory is planned unless someone can show a plausible exploit at present. I am convinced that no such exploit exists at present.
The custom fields management routines improperly escaped table and field names, allowing for sql injection in the arguments of these routines. These routines execute data manipulation language statements against the database, altering the tables which store custom fields. They are not exposed to the user interface of the application and are intended for consultants to use when providing customizations against the software. Typically these are run from a general-purpose database administration program (like pgAdmin) or console (like psql). The routines run with the permissions of whoever invokes them so they pose no privilege escalation issues. Because they are run from a general purpose administration tool, it is possible for the person who runs these to execute arbitrary SQL without resorting to an exploit. Because they are not exposed to the application, there are no currently supported environments which suppose that one is only able to run these routines. In this specific case, there are no specific exploits against this code which allow someone to do things they could not do by just issuing normal SQL statements. Therefore this is not believed to pose a security problem at present. I have however decided to commit a fix, and there are two reasons for doing so. The first is just that bad use cases cause problems with the current API. Any time the API behaves unpredictably there is a potential for problems. It is better to support to some extent braindead customizations (using single and double quotes in custom field names, for example) than to declare those as unsupported. It also might increase the exposure to social engineering attacks. The second is that a non-exploitable problem today can possibly lead to exploitable problems tomorrow. People may read the code in question and emulate the errors in it, or they may code applications against that API which would then have relevant vulnerabilities. A hotfix is available currently in most recent SVN. The file is sql/fixes/new_custom_fields_funcs.sql. This is not a critical fix. The number of active installations that this should affect is exactly zero at present, barring unusual extensions to the software. However for those interested in the fix, the hotfix is available. For those who are coding sql routines, please be aware these problems can exist, and therefore make sure you properly use quote_literal and quote_ident in your stored procedures. Best Wishes, Chris Travers ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
