|
Date: Wed, 4 Apr 2012 11:07:05 +0200 From: Steffen Dettmer <steffen.dettmer@...glemail.com> To: oss-security@...ts.openwall.com Subject: Re: Re: [JDBC] CVE DISPUTE notification: postgresql-jdbc: SQL injection due improper escaping of JDBC statement parameters On Mon, Apr 2, 2012 at 6:16 PM, Kevin Grittner <Kevin.Grittner@...ourts.gov> wrote: > ... which shows version 8.1 as having reached end-of-life and gone > out of support five years after release, in November, 2010. Thank you for sharing your view. Let's me take this opportunity to tell my arguments why I think an advisory with this information could be suited. Yes, all this is true. However, not everyone knows all that and can "apply usual expectations". So you don't have old clients running anywhere? Others may follow the idea not to change a running system (at least as supported by vendor) but for some reason upgraded one of their databases to a newer version. Is this such an unlikely situation that some few old applications connect to a database which later is updated because some newer applications benefit from newer database features? Or because the database server hard- and software is upgraded to keep increasing performance requirements? Of course for an expert focusing PostgreSQL / JDBC all this is known, clear and obvious, but for the less experienced people, for example application developers, it might not be the case. Java developers may follow "run everywhere" as long as the test suites pass (which might not include security penetration testing and even if so may fail to detect the problem). Who is in charge to know that such a combination is insecure? The application vendors might not know which JDBC / DBMS combination a customer might use. At the customer site IT professionals may choose supported distributions and may not know details of PostgreSQL version requirements, especially if not stated in the manuals. The last 8.1 version (build) is from 2010, so someone could assume it would still be supported. I think this shouldn't be mentioned only somewhere on a web page, but in the appropriate users manuals. Often so many things are used by projects that it could be very hard trying to read all related mailing lists. When using a linux distribution that is still supported by the vendor, I think it is reasonable to assume the included packages are still supported at least by the same vendor. I talked with a (very) few people, no one had assumed that; the assumption was "install all vendor patches and be safe for known issues" and that different versions either work securely or not at all. IMHO also misleading seems to be the term "protocol version 3". I think this really suggests that any protocol version 3 client could connect to any protocol version 3 server. But this is not true. There are many different protocol version 3 versions, but I don't think that this is commonly understood by end users. I know that it is nowhere told that it would be interoperable, but I think a common assumption would be that protocol v3 is interoperable with protocol v3. The current situation seems to be "you cannot use older versions of your enterprise long term support distribution to connect newer versions of your enterprise long term support one", which in my point of view had been worth an advisory, but maintainers seem to conclude that what is not supported from the project does not need to be supported by the distribution. Maybe maintainers could decide to provide an advisory anyway, be it only summarizing the issue. I understand that creating a patch would be much effort, is not supported and disliked, but spreading the information could be suited nevertheless. Distributors could decide to pack newer versions. Even if not, Distribution customers then at least could decide to upgrade their systems and/or manually install a suited driver version. Knowing the issue is needed in any case, I think. oki, Steffen
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.