Thursday, August 14. 2008Responsible Disclosure, and Amarok 1.4.10Yesterday we released Amarok 1.4.10, an unanticipated security release. From the Release Anouncement you may notice that we gave thanks to Google Alerts for notifying us of this vulnerability. This was perfectly accurate. Read on for why. I want to say up front that the security value of this vulnerability rates so low that it's amazing Secunia even bothered with it. It requires local access (or at least, a shell prompt), and it requires our code parsing a file whose name was hardcoded to execute the code (doesn't)/overflow a buffer (doesn't)/do things incorrectly (doesn't). At worst, you could maybe make Amarok crash, and since this would be a race condition, you'd have to be extremely lucky, and this could only happen between when the user was downloading the Magnatune database and when it was being parsed. Not exactly mission-critical. So, the actual threat of the vulnerability was approximately nil. That wasn't the driving factor behind the sudden release -- the driving factor was the fact that since Secunia did issue an advisory, we wanted to respond to it as soon as possible. Which should have been 36 hours before. Here's where the bungling comes in. At midnight Tuesday morning, Dwayne Litzenberger posts a bug report on the public Debian bug tracker with snippets of code from Amarok, and the following: I'm not familiar enough with Qt to be sure, but it looks to me like the code creating a temporary file insecurely. At minimum, I think this code will break if another user has already created /tmp/album_info.xml (thus preventing the current user from deleting it). Now, I'm more familiar with the KDE and Gentoo bug trackers, which explicitly ask you to not post security related information there, but to contact the projects directly (this would be in following responsible disclosure guidelines). Debian's bug tracker doesn't seem to say this, but it's hard to say -- in a couple minutes of looking around, I didn't see a link that would let me file a new bug directly. It seems you have to either email it in in a certain format or run their reportbug tool. But as I was saying -- it gets posted to the public bugtracker, and Dwayne doesn't actually contact us directly. Neither does Debian. Perhaps they don't have bug triagers like I'm used to in Gentoo, and perhaps the maintainer of the package wasn't around for those 36 hours. Perhaps they simply didn't bother -- after all, we recently found out that Debian has created several patches for 1.4 over the years that their maintainer(s) never forwarded upstream. Mid-Wednesday, Ian gets a Google Alert for Amarok -- Secunia has issued a security advisory against us. This is how we first find out about it, which was apparently considered enough of a vulnerability for Secunia to bother with it. Dwayne didn't notify us. Debian didn't notify us. Secunia didn't notify us. No one bothered. This doesn't exactly correspond to normally followed responsible disclosure guidelines. A fellow developer thinks "Joe User" -- in this case Dwayne -- shouldn't be expected to know those guidelines. I don't buy it. If you know enough about security to recognize a vulnerability, you should know enough to properly disclose it. My fellow developer also thinks that Dwayne acted responsibly, letting the world know about the vulnerability as soon as possible so that users could arm themselves against the problem until it was fixed. This is wrong, and easily seen to be wrong. Let's forget for a moment that the vulnerability was miniscule in terms of threat level, and just think about it in terms of being a vulnerability, to prevent yourself from thinking "well yes, I see your point, but it was really miniscule" -- because that's not the problem with what happened here, and next time the vulnerability could turn out to be major. Had Dwayne notified us first, instead of posting on the Debian bug tracker and letting it lie:
By not following responsible disclosure guidelines, any users concerned about Amarok's security were unaware of, and running, unpatched software for at least a day and a half longer than if responsible disclosure guidelines had been followed. Far from letting the users know so that they could act to protect themselves, the users actually ended up being the ones getting screwed here. Now, I will say something in Dwayne's defense, on the off chance that he could spot a security bug but really didn't know responsible disclosure guidelines -- on their bug tracker, Debian has the following piece of information: Don't file bugs upstream: If you file a bug in Debian, don't send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream. In this case, the first "if" in that sentence should have failed -- it shouldn't have been filed in Debian's bug tracker. But even if the user decided they want to put it there, security bugs shouldn't be included in this -- they should not initially be public, in following responsible disclosure guidelines; or, if Debian wants security bugs to go through its public bug tracker as well, they should be on the ball and not sit around on these reports for more than 36 hours. So, to wrap up: disclose security bugs you find in a project properly. Contact the project, and if you must post it publicly somewhere before giving the project a reasonable chance to respond, don't sit on it, but contact the project as well and make sure they know about it so they can start fixing it. Do it right, and the one getting the credit for notifying the project won't be Google Alerts; it'll be you. Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Indeed, after reading the Secunia advisory I had wondered why it was labeled a security vulnerability at all. If a intruder already has shell access they can run kill -9 `pidof amarok` (or similar) to achieve a Amarok crash.
This is a bug, but not a security bug. This is in the same category that Microsoft employee Raymond Chen has complained about before (http://blogs.msdn.com/oldnewthing/archive/2008/05/16/8510192.aspx), bugs that are labeled security bugs but actually are not.
Yep. I can't help but notice that it's in Secunia's self-interest to label it as a security bug...
That being said, Secunia is a major name. I'm sure you can understand why it didn't make sense to get into an argument with them over why it was a security issue or not when it was trivial to fix; nor did it make sense to have it sitting open. We don't want to look unresponsive to security issues...next time it could be a real one. Besides, think of the poor people at work whose sysadmins go by what Secunia says and tell them they can't run Amarok anymore  What would have happened if Dwayne had come to us first? Probably we would have first discussed with him whether or not it was actually a security problem. But Secunia forced our hand. And the entire situation ended up providing a good demonstration of the issues with not following responsible disclosure guidelines, regardless of the severity of the bug.
An ordinary user cannot kill another users processes, but he can create a file in /tmp, when he knows the name of the file another users process will pick up from there. This is a valid vulnerability.
But it's not, because as I said in my blog entry, it relies on Amarok to do bad things with this file that it doesn't do.
The first thing Amarok would do would be to delete the file if it already existed. This would happen just before data was saved to the (newly created) file, which would happen just before the file was then read by the next process. If it couldn't delete the file that was there, it would abort. So already you introduce a very small time frame for the attack to occur, which would likely require knowledge of what the user running Amarok is doing, since updating the Magnatune database does not happen very often, and only when the user requests it. So you have a race condition involved in the exploit, and it's very tight -- in the Amarok code it goes from one to the other, and realistically you have less than a second, if that (probably much less), on a modern machine in which to get your file slipped in there. Note that Amarok does not dereference symlinks during the delete process, so you can't have Amarok delete another user's file when it's removing the file under /tmp, unless you were able to move that file to that location in /tmp yourself (in which case, you don't need Amarok to attack the file). Now, let's say you do manage to slip your own file into there, overcoming the race condition. The file is parsed as XML with Qt's built-in classes. Assuming Qt's XML parsing classes and string handling clases don't have strange vulnerabilities, from the Amarok side at least, everything is treated as a string and nothing in that file is ever executed. So the worst that could happen is you populate Amarok's Magnatune database tables with strange, invalid information (which would be overwritten next time it the Magnatune database was downloaded); or perhaps you'd cause Amarok to crash during the parsing. The only other way you could end up causing issues is if some of the keys in the file (URLs) contain bad stuff and get passed to kdelibs KIO classes -- but then that'd be a kdelibs problem, not Amarok. The permissions needed to execute the attack, the split-second race condition, and the fact that the code is never executed and is treated as read-only strings mean that this "vulnerability" is pretty much a non-event. Which is why this post was about proper disclosure, not about the vulnerability itself.
I didn't argue, if this is exploitable, but wanted to point out that Michaels intruder theory is beside the point.
But - isn't hardcoding such a temporary file instead using KDE's KTempFile class not a bit embarrassing, given that tmp file vulnerabilities are a very classic issue!? That said, I'm not fond of the global writable /tmp standard, instead requiring the system to provide /tmp/$user, which would safe us from these tmp file vulnerabilities popping up here and there again and again.
That's why it was fixed to use KTempFile.
"If it couldn't delete the file that was there, it would abort."
I could not reproduce this behaviour. A precreated symlink (without playing a race condition) would not be deleted by Amarok (if it is attacker-owned and in sticky /tmp), and Amarok would overwrite contents of an attacker-chosen file owned by the victim. If you cannot reproduce this on your machine, please join the discussion on our Gentoo bug (in "Homepage").
I'm sorry, you're right -- it would not abort. So if you have tested it and can in fact attack a user's file that way, then the race condition I mentioned is not valid.
Sorry to go a bit OT here, but: "after all, we recently found out that Debian has created several patches for 1.4 over the years that their maintainer(s) never forwarded upstream"
Isn`t that what some members of debian is always badmouthing ubuntu for? Pot meet kettle, anyone?
Re: Responsible Disclosure
Almost any "bug" might have a security impact of some sort or another. I honestly don't see how the security impact of this bug is any different from any of the other myriad race conditions, off-by-one errors, or buffer overflows that are constantly reported in popular free desktop software today. Demanding "responsible disclosure" for something like this is ridiculous. Guy found a plain old ordinary bug, posted it on a public list, and Secunia issued yet another one of their worthless advisories because they happened to see the word "insecurely" in the bug report. I find it irresponsible to berate some guy on a bug tracker because he didn't present a bug to the exalted developer on a silver platter. "Responsible disclosure" in my opinion should be reserved for extreme cases on the order of Debian OpenSSH fiasco, and in any case, it's a personal decision for the discloser. Grow a thicker skin and don't release your source if you don't want people to discuss it publicly.
To quote from the article:
"I want to say up front that the security value of this vulnerability rates so low that it's amazing Secunia even bothered with it." In other words, the "security" impact of this bug is not significantly greater than that of any of the other thousands bugs that are reported all the time on countless open source software projects. Are you implying that all bugs should go through some "responsible disclosure" process? We may as well shut down all public bug trackers then. There is a time and a place for the responsible disclosure of security vulnerabilities, but for run-of-the-mill bugs, like this one, which has, in your own admission, minimal security impact, it's perfectly acceptable and normal practice to disclose them publicly. It is not acceptable to publicly flame someone for reporting a bug with minimal security impact on his disto's bug tracker. So what was the point of the article that I missed?
You're missing the point because you're applying hindsight to the situation and focusing on the security impact of this particular bug. You're missing the forest for one tree. The point of the article was that responsible disclosure practices benefit users and can lead to the users being protected against security issues faster than simply dumping the information out there. That despite the view some hold that the moment you find something you should make it public so users can protect themselves, that users can be far better off by following accepted security disclosure methodology.
Once the bug reached us, and once we analyzed it, we decided that, despite the Secunia advisory, the threat level was minimal. But that's completely hindsight, and took place after Secunia had filed their advisory (see comment #1.1), and most importantly, the reporter *didn't know that*. He recognized that it could pose a security threat but seemed unsure as to what level. He didn't post saying "you may want to fix this, but don't worry, it's really almost impossible to exploit." If you don't know the criticality of a security flaw that you think you found, you should be responsible, because it may be more serious than you anticipated.
Well, it wouldn't have been fixed so quickly if he hadn't reported it publicly.
Of course - because it would have been fixed WAY quicker.
Have you read this article at ALL?
Heh. Thanks, klon.
This is not an Amarok vulnerability. Any application that would just blindly use a file found in /tmp without first verifying it is vulnerable. /tmp is wide open and anyone with a shell account can create what ever in there. That is the intent of /tmp.
"Any application that would just blindly use a file found in /tmp without first verifying it is vulnerable."
Well, if Amarok was doing that, then according to your words it is vulnerable, despite your first sentence. Anyways, the merits of the Secunia advisory have been discussed already. |
Amarok LinksCalendar
QuicksearchCategoriesSyndicate This BlogBlog AdministrationWe Listen To... Powered by
|
||||||||||||||||||||||||||||||||||||||||||
