Skip Menu |

This queue is for tickets about the DBD-Pg CPAN distribution.

Report information
The Basics
Id: 44880
Status: resolved
Priority: 0/
Queue: DBD-Pg

People
Owner: Nobody in particular
Requestors: bryce2 [...] obviously.com
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: 2.9.2
Fixed in: (no value)



Subject: Extra null termination in quote.c
In quote.c dequote_bytea() is a function that has changed a lot with each release of DBD::Pg. In version 1.49 it has a memory leak (loosing a buffer it allocated). Past 1.49 it null terminates the buffer in a curious way: void dequote_bytea(char *string, STRLEN *retlen, int estring) { ... *result = '\0'; return; } Curious, because the result of BYTEA decode is NOT null terminated. Nobody should be treating that result as a null terminated string. -------------------------------------------------------------------- This is a patch against 1.49 (the last in the 1.XX series) for the memory leak: # diff quote.c.old quote.c 308,310c308,309 < New(0, result, strlen((char *)string)+1, unsigned char); < < result = string; --- Show quoted text
> /* New(0, result, strlen((char *)string)+1, unsigned char); */ > result = string; /* Dequote by chasing in supplied buffer */
336,338c335,339 < result = '\0'; < Renew(result, (*retlen), unsigned char); < string = result - (*retlen); --- Show quoted text
> /* result = '\0'; */ > /* Renew(result, (*retlen), unsigned char); */ > /* string = result - (*retlen); */ > > *result = '\0'; /* Wrong, as BYTEA is not null terminated, but this
matches 2.12.0 code */
Show quoted text
> *result = '\0'; > return; > } > > Curious, because the result of BYTEA decode is NOT null terminated. > Nobody should be treating that result as a null terminated string.
ISTR it's simply a safety measure - while calling code should use the string length to grab the last byte, there is no sense in not adding a tailing null. The dequote functions are called in a very abstract way, and make their way back to chars/svs within dbdimp.c. Thanks for the patch for 1.49, but I'd urge anyone reading this still running that version to upgrade, as there are many, many other fixes outside of that one memory leak. :)
The bug is present in Debian Etch, which is still a widely deployed stable server version. The above leak was used in a DoS attack on such a server, making the system about 3x more vulnerable to the attack (because of the magnifying effect of mod_perl, and heavy use of BYTEA). Debian Etch users can't readily upgrade DBD::Pg, as Lenny's package requires a perl upgrade also. This memory leak has been assigned CVE-2009-1341 by mite.org. While old, many sites don't run the bleeding edge, instead relying on older stable (but still security patched) releases. That's exactly the case here, Debian Lenny came out only early in 2009, and we won't follow it until 6+ months later. Thus we depend on Etch still, and Etch depends on DBD::Pg 1.49. I believe the same is true of various still-supported RedHat and SUSE releases. Any future tracking and fixes should reference CVE-2009-1341
Here's the release docs. There is a large community behind stable enterprise Linux (e.g. behind the bleeding edge): ------------------------------- Released : 28 April 2009 Package : libdbd-pg-perl Vulnerability : several Problem type : local (remote) Debian-specific: no CVE Id(s) : CVE-2009-0663 CVE-2009-1341 Two vulnerabilities have been discovered in libdbd-pg-perl, the DBI driver module for PostgreSQL database access (DBD::Pg). CVE-2009-0663 A heap-based buffer overflow may allow attackers to execute arbitrary code through applications which read rows from the database using the pg_getline and getline functions. (More common retrieval methods, such as selectall_arrayref and fetchrow_array, are not affected.) CVE-2009-1341 A memory leak in the routine which unquotes BYTEA values returned from the database allows attackers to exhaust system memory. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1341 http://www.debian.org/security/2009/dsa-1780
Show quoted text
> While old, many sites don't run the bleeding edge, instead relying on > older stable (but still security patched) releases. That's exactly the > case here, Debian Lenny came out only early in 2009, and we won'tfollow > it until 6+ months later. Thus we depend on Etch still, and Etch > depends on DBD::Pg 1.49. I believe the same is true of various > still-supported RedHat and SUSE releases.
Is there anything you need us (maintainers) of DBD::Pg to do about this issue?
Closing, as there seems nothing else we can do on this end. Please reopen if this is not the case.