Bug 154218 - app-arch/rpm: buffer overflow
|
Bug#:
154218
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: falco@gentoo.org
|
|
Component: Vulnerabilities
|
|
|
URL:
http://secunia.com/advisories/22740/
|
|
Summary: app-arch/rpm: buffer overflow
|
|
Keywords:
|
|
Status Whiteboard: B2 [glsa] Falco
|
|
Opened: 2006-11-06 01:53 0000
|
Hi Sanchan,
a vulnerability here against app-arch/rpm, fixed in CVS.
TITLE:
RPM Buffer Overflow Vulnerability
SECUNIA ADVISORY ID:
SA22740
VERIFY ADVISORY:
http://secunia.com/advisories/22740/
CRITICAL:
Less critical
IMPACT:
DoS, System access
WHERE:
From remote
SOFTWARE:
RPM Package Manager 4.x
http://secunia.com/product/12490/
DESCRIPTION:
A vulnerability has been reported in RPM, which can be exploited by
malicious people to cause a DoS (Denial of Service) or potentially
compromise a vulnerable system.
The vulnerability is caused due to a boundary error when processing
certain RPM packages. This can be exploited to cause a heap-based
buffer overflow by e.g. tricking a user into querying a specially
crafted RPM package.
Successful exploitation may allow the execution of arbitrary code,
but requires that certain locales are set (e.g. ru_RU.UTF-8).
SOLUTION:
Fixed in the CVS repository.
PROVIDED AND/OR DISCOVERED BY:
Vladimir Mosgalin
ORIGINAL ADVISORY:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212833
I'll try to have the fix in portage as soon as possible. The issue is not so
critical beacuse rpm seems to be totally broken (bug #153974, #153292, #153280)
and doesn't work at all. I'm trying to have at least one version working.
Another reason for the low level of severity is that the overflow vulnerability
can be exployted only with LANG=ru_RU.UTF-8.
Upstream patch in portage for rpm 4.4.6 and 4.4.7, version bump for security
fix.
Thanks Sandro . This was really fast !
Since when do we mark (security-)bumped packages directly as stable?
(In reply to comment #5)
> Since when do we mark (security-)bumped packages directly as stable?
>
I don't know, but as far as I can remember it is the policy for security-bump
of stable ebuilds.
Tobias, Sandro just to clarify: it's usually up to the package maintainer
wether to bump directly to stable or let arches do the stable marking.
Tobias, yeah that is normal procedure. For very small fixes/very urgent issues
maintainers sometimes bump directly to stable.
Ok then ... I was just kinda confused as I'm watching bug-mails for the
security@g.o alias now for nearly two years and can't remember seeing a bump
directly to stable in that time.
GLSA 200611-08, thanks everybody