Bug 603244 - (CVE-2010-2197) CVE-2010-2197 rpm: rpmbuild does not properly parse syntax of spec files
CVE-2010-2197 rpm: rpmbuild does not properly parse syntax of spec files
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
public=20100608,reported=20100608,sou...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-11 21:37 EDT by Vincent Danen
Modified: 2010-06-15 07:33 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-14 11:26:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2010-06-11 21:37:52 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2010-2197 to
the following vulnerability:

Name: CVE-2010-2197
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2197
Assigned: 20100608
Reference: CONFIRM: https://bugzilla.redhat.com/show_bug.cgi?id=125517

rpmbuild in RPM 4.8.0 and earlier does not properly parse the syntax
of spec files, which allows user-assisted remote attackers to remove
home directories via vectors involving a ;~ (semicolon tilde) sequence
in a Name tag.
Comment 1 Vincent Danen 2010-06-11 21:46:30 EDT
This was originally reported here: https://bugzilla.redhat.com/show_bug.cgi?id=125517#c13

I don't believe we can consider this a flaw.  There are easier ways to remove a home directory in the spec file itself, since it is a glorified shell script, so I don't know why you would need to do:

Name: foo;~

instead of simply:

%prep
rm -rf ~/

which results in:

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.98141
+ umask 022
+ cd /home/vdanen/svn/el/trunk/srv/RHEL5/build-srv-0.27.1
+ rm -rf /home/vdanen/
rm: cannot remove directory `/home/vdanen/': Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.98141 (%prep)
...
% cd ~
% pwd
/home/vdanen
% ls -al
total 8
drwx------ 2 vdanen vdanen 4096 Jun 12 05:44 .
drwxr-xr-x 3 root   root   4096 Jun 12 05:43 ..

If you can remove a home directory in %prep like this, does it really matter if there is trickery in the Name: field or anything else?  Either way it's malicious.

I might call this a bug, but I don't think I would call it a security issue.
Comment 2 Vincent Danen 2010-06-11 21:56:56 EDT
Statement:

We do not consider this to be a security issue as it does not introduce any additional risk in using untrusted RPM .spec files.  RPM .spec files can do a lot of things, regardless of how rpmbuild parses the syntax, because certain sections of the .spec file (%prep, %build, etc.) are treated as shell scripts.  Because of the ability to easily include malicious commands anywhere, an untrusted .spec file should be carefully examined prior to building, the same as if you were to download and execute an untrusted shell script.
Comment 3 Jeff Johnson 2010-06-14 16:18:07 EDT
The distinguishing issue is that RPM itself can be tricked into
removing home directories.

There are other means to establish "trust" of a spec file, including clearsigning.

If removing POSIX ACL's is _NOT_ worthy of a CVE because RPM never sets them,
rpmbuild (in this case) can be tricked into removing home directories no
matter what delusions of "trust" you may have.

Should cross-site scripting issues in PHP be dismissed because the content
"does not introduce any additional risk" and because PHP content "can do a lot
of things".

Surely you can see trhe logic flaw there ...
Comment 4 Jeff Johnson 2010-06-14 16:35:11 EDT
You also need to find the report of the issue: #125517 is most certianly
_NOT_ relevant since it deals wioth rpm install/upgrade, not rpmbuild.

At the time (in spite of your opinion now) the bug was marked
EYES-ONLY security
Comment 5 Matt McCutchen 2010-06-14 23:26:37 EDT
(In reply to comment #3)
> The distinguishing issue is that RPM itself can be tricked into
> removing home directories.

How does that make it a vulnerability?  The security model of rpmbuild has always been that the spec file is allowed to do anything to the user's account.

> There are other means to establish "trust" of a spec file, including
> clearsigning.

You are welcome to use the integrity protection technology of your choice on the spec file before passing it to rpmbuild.

> Should cross-site scripting issues in PHP be dismissed because the content
> "does not introduce any additional risk" and because PHP content "can do a lot
> of things".

Are you quoting a particular bug report here?  You'll have to be more specific for me to understand the comparison you're making.
Comment 6 Panu Matilainen 2010-06-15 03:57:46 EDT
Obviously nobody bothered to actually verify Jeff's rant.

[pmatilai@dhcp102 SPECS]$ rpmbuild -bb foo.spec 
error: line 1: Illegal char ';' in: Name: foo;~

This is what rpm >= 4.6.1 does. Older versions (<= 4.4.x, 4.6.0) might go indeed eating your home directory here, but the maintained versions don't fall to that particular trick. No doubt there are similar /other/ tricks possible though... a SELinux locked down sandbox for rpmbuild would be nice thing to have.
Comment 7 Jeff Johnson 2010-06-15 07:12:57 EDT
Re comment #5:

With "untrusted" content the usual approach is examination looking for
(as in your example)
     %prep
     rm -rf /

And with rpmbuild, the widespread quoted wisdom is
    Never run rpmbuild as root.

The exploit is not obvious (since it involves obscure syntax), and there
are forms of damage that can be accomplished without root access
that makes the wisom foolish,

The bug report was from Seth Vidal in late March, early April 2009.
Do your own busy work.

And yes
    Name: foo;~
isn't the syntax. You should find a reproducer attached to the bug report,\
if not, I'll refigger the syntax flaw. Most of the issues are now fixed.
Comment 8 Jeff Johnson 2010-06-15 07:20:36 EDT
Re: comment 6:

You cannot plug the exploit by filtering known risky characters in Name: and Version:. You MUST
run a permitted character set, because there are other more twisted syntaxes
that can be used for the exploit as long as the value of the Name: tag is
inserted into a shell expansion point in %setup.
Comment 9 Jeff Johnson 2010-06-15 07:33:14 EDT
To illustrate what I mean by "permitted character set" consider a URL.

Even if you, say, detect and deny a '~' character in the URI, explictly, there is
always the "%7e" form that will be converted back to a '~' character, voiding
the approach of filtering the known bad '~' character.

Simular transforms exist in shell expansion points after (in shell syntax)
a '<' redirection.

Note You need to log in before you can comment on or make changes to this bug.