Thursday, August 14. 2008
Responsible Disclosure, and Amarok 1.4.10
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.
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.
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.
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.
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 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?
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.
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?
"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.
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?
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.
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 Links
Calendar
|
September '08 |
|
||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
Quicksearch
Archives
Categories
Syndicate This Blog
Blog Administration
We Listen To...
Powered by
