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.
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.
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.
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 ...
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
(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.
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.
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.
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.
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.