Who cares about how it behaves on a larger data set? The point is that, if it weren't for the non-uniformity in the results, it'd be fine for what they have.
So, for practical values of "infinite loop", the probability is nonzero.
Yeah, but it's equally true that it's pretty clear that the probabilities of it going a while are very low. I mean, this guy did probably tens of thousands of tests; if there was even a half decent chance of one of them taking a while he'd have noticed.
Long story short: - Not an infinite loop by a theoretical sense - Not really an infinite loop by a practical sense
IMO that sort of stuff falls into the "crappy definition of 'can'". I can't think of any remotely reasonable implementation of Quicksort that would have that behavior.
As the author of the article pointed out, this technique can cause an infinite loop.
For certain, pretty crappy definitions of "can". First, you'll notice he also points out that that "depends on the sorting algorithm used". I don't think that the most likely choices (Quicksort in particular) fall victim to this. Second, the other poster is right: the probability that it's actually an infinite loop is 0.
Is picking a worse random number generation function (the default one in C and JS) really fucking up?
There's no problem with the function they're using; the problem is how they're using it. If 'rand()' were perfect, their technique would still suck.
I can already see all the comments how MS would be favoring IE with this (summary conveniently left that one out), but as it is they're promoting the other browsers almost double more.
I do think the summary should have mentioned that bias, but I don't think it's quite as good a position as you convey. I bet the far right position is better than #3 and #4 at least.
(If I wanted to put on my conspiracy hat -- which I don't, I don't really believe this -- I'd say that MS wanted to bias it towards them and decided that biasing it toward #1 would be too blatant, but that #5 was "good enough".)
Given that each user is only going to see this screen once per computer, I'd say simply using the seconds of the current minute as a random seed should be OK
This problem has nothing to do with how the PRNG is seeded.
The word "seed" doesn't even appear in TFA at all.
Why not? Is the author suggesting that random functions in use today are somewhat deficient? What is his solution?
You know, it's really too bad that the author of the article the summary linked to didn't write up an article answering exactly that. Then maybe Slashdot could have linked to it.
(In a nutshell, the answers are, respectively: "because plopping a 'rand()' into your code doesn't mean that what you'll get out is uniform", "no", and "use a shuffling algorithm that works.")
There were some folks a while ago who wrote up a security investigation they did of Party Poker's site.
One of the problems they had was a terrible, non-uniform shuffling algorithm. Completely different problem than what MS did, but interesting nonetheless. (I actually guessed that this is what MS did, but that's not the case.)
If you didn't know there was a law enforcement back door in everything Microsoft does, well, here's your proof.
Actually I would say that the documents indicate almost the opposite.
They'll give you information that MS has on the servers, but not information that's just on your XBox. To wit: 'Be aware that users may also store e-mail content on their computer's hard drive. Microsoft will not be able to disclose e-mail content stored on a user's computer --- only e-mail content stored on Microsoft's e-mail servers.' In other words, there isn't a backdoor onto the actual XBox.
Except it won't. You can't email a file that will run on a double-click -- unless your mail reader supports.desktop, the only file that allows things to execute without itself being executable.
Please read what I said. I said "And I still think you're deluding yourself if you think that adding 'just double click on the file and choose extract' in the email wouldn't catch a sizable population of people".
I guess I could have said "mail a TAR file" there too, but the point is that if you put those instructions in, the file you mail out wouldn't need to be executable.
I plan on putting together a demonstration of how I think this attack could play out, but it'll take a couple hours that I won't have for the next couple of days, so check back sometime over the weekend.
This is exactly the problem. No other kind of file, no matter what is in it, will run anything unless it has executable permission, so user can click on things until his mouse will wear out, and all he will see is viewers.... Except now there is one exception to this rule --.desktop, the only broken link in the chain of distrust.
To be fair:
- At least Ubuntu's configuration of Gnome asks for confirmation the first time you run a particular.desktop file, asking you if you want to add it to a trusted list, just run it, or do nothing. It's possible this is a new feature. So.desktop files aren't even as vulnerable as you think.
- Also, I don't see a.desktop file playing any role in my attack, except to the extent that it falls into the autorun folder; once there the exact protocol for how it's run (exec bit or no) is pretty irrelevant.
Running executable not installed by a package manager or a sysadmin, and not written by the user himself is something that no user should ever do on a non-Windows system.
On my system at work, I have a couple gigs of software I have installed to ~ because I don't have root.
I probably should check PGP signatures... but I don't.
(Just FYI, except for installers, there's barely more reason to run an executable on Windows than there is on Linux. And if you don't trust the installer, why do you trust the package from the package manager?)
It only happens because on Windows "Run" and "Open" are the same action in GUI...
I don't know if you noticed, but this is the same on Linux, at least with compiled executables. (I did notice that for scripts it asks if you want to open or run.)...and almost everything is distributed as an executable. Even things that have no actual executable content are often in self-extracting archives.
Actually I'd say this doesn't matter all that much... half the time the virus uses the old "foo.jpg.exe" trick so that it doesn't even look like it's a program in the first place.
(Granted, this problem goes away somewhat on Linux.)...any modern GUI will steer such user into a viewer and won't create an executable file unless user selects "Extract" option, then selects or makes a target directory.
And I still think you're deluding yourself if you think that adding "just double click on the file and choose extract" in the email wouldn't catch a sizable population of people if the world was instantly moved from Windows to Linux (if people were as proficient with Linux after the switch as they are with Windows now).
No, I would just make a special "interpreter" that takes existing.desktop format plus #! line and runs whatever is in "Exec" entry.
Oh, I think I may understand your beef with the.desktop files now: you can actually launch what's in the exec line by double clicking on it. Is that your problem?
If so, I somewhat see where you're coming from. I was only thinking of them as files that were read when Gnome logged on, so double clicking on them didn't enter the picture.
All GUI archive managers require a separate "Extract" command (that preserves execute permission), that is different from the default action that is to view a file (without giving it an execute permission even if it is present in the archive).
I have to admit I only tried "tar xvf" to verify that permissions were preserved. Nevertheless, you really think you couldn't get people to actually extract an archive?
For anyone but total newbies it should be obvious that the user should NEVER run anything he downloads unless he is installing some software that is not in a repository -- as root, as his own user or as anyone else.
And because I ran out of words in that sentence before links, here are some more: 12.
To put those into context, those are all links from Wikipedia's "Timeline of Notable Computer Viruses and Worms" from the last decade, including the only two entries on that page from 2009 and 2010. Most of the above had a noticeable amount of mainstream press coverage at the time, and the list includes names like ILOVEYOU, Sobig, MyDoom, and Storm.
Sure, they aren't the scariest worms out there, and over the last few years they haven't been the most damaging. But at the same time, if I got to bet whether a manually-spread trojan is worthwhile, I know which side of that bet I'd take.
Personally I would just turn them into traditional #! scripts with "interpreter" doing what a file manager would, and file manager refusing to execute anything in them unless they are executable.
The.desktop files contain rather more information than just what program to run. How would you deal with that? Specially-formatted comments in the script? Pass the script a command line argument?
Besides, it's not like running scripts without execute permissions is a new concept. "source foo.sh", ". foo.sh", "perl foo.pl", "python foo.py", etc. IMO are all comparable to Gnome looking into the.desktop files on boot to see what to run.
I don't know how it works everywhere else, but in the UK if there isn't significant indication that you shouldn't be somewhere then you aren't trespassing. Thus, an open doorway with a sign saying "No Entry" means you are trespassing if you go past it, but an open doorway is effectively an allowable entry point for the public.
What about a closed door?
Let me ask this. Let's say I put together a site with a login page. When I create the form, I have the choice between submitting the form as a GET or POST request. Should it make a difference as to whether someone trying passwords in the "password" field is "in the right"?
Suppose I make the (poor) decision to submit with GET. Is there a difference between someone using the form to guess passwords vs. seeing that the password is in the URL and just trying different things after "?password="?
Finally, let's say I change the submission script a bit so I use Javascript to redirect the user to "example.com/login/password" instead of "example.com/login?password=password". Is there a difference between those?
And at that point, what is the "attacker" doing that isn't just guessing a URL?
Somewhere in here there has to be a distinction between guessing someone's password and guessing a URL, but I have to admit that I don't quite see where it is. Is it the final difference, because you could expect someone to know that "?password=blah" indicates that it's supposed to be restricted? I dunno.
Don't want people reading your web site? Put it behind a login. Anything else is just sophistry to cover up incompetence.
While I do agree, and think that criminal investigations and such in this case are ludicrous and hope they don't go anywhere, part of me does wonder... what's the difference between a non-linked document where you don't tell people the URL and a site with a password?
Would guessing 3000 different passwords be as forgivable, even if the system doesn't cut you off? Is an easily-guessed URL any better than an easily-guessed password?
Having to chmod the.desktop files in.config/autostart wouldn't really change anything about my technique; you'd just have to add one more step to do chmod +x trojan.sh.desktop after creating that file. The thing the user runs to set all this up would have exactly zero difficulty doing this.
It assumes that there is a constantly-running hostile process, what means, pretty much everything that desktop environment does may be altered at that point.
Ah, but it doesn't mean it has to be. Often malware is better-off remaining unobtrusive so as not to draw attention.
Assuming that user did not run chmod +x on everything he downloads, this would require a completely separate exploit to happen before the user does anything privileged.
Oh stop with the BS. You and I won't run stuff that we download, but I guarantee if the place of Ubuntu and Windows were switched today, within a month you'd see Canonical push a security update that changes sudo's configuration, a sizable number of Ubuntu boxes rooted by this technique, or both.
Hell, all the malware writer would need to do is put things into a.tar.gz file and say "extract and run".
The difference is, this is the race against the user, not another process. Smart user will invalidate timestamps before doing anything that involves a non-administrative applications anyway...
Huh? What I gave a demonstration of requires no user action besides (1) running the user-local trojan (that would install itself in the startup apps) and (2) sometime, runing something that is started with sudo directly by gnome.
They do not have to run sudo then something non-privileged.
Ah, I think I see what was going on. It was keeping my credentials cached both (1) from one login to the next and (2) even though I was issuing 'sudo -k' and 'sudo -K' in an xterm.
I already said that sudo does some parent checking to make sure that two invocations don't reuse the same tokens if they don't share a parent; apparently -k/-K only removes the tokens that it would clash with.
So that mystery is solved; both versions have the same behavior in this respect (which shows why you don't need to be lucky to cache credentials).
BTW, on this general topic, I highly recommend this paper (PDF) from the Usenix security conference in 2005. The bottom line from it is if you say "eh, this is hard to exploit as you have to be unbelievably lucky", you definitely can't discount the chance that there's a way for the attacker to stack the dice in his favor.
I know I've already posted like a gagillion times, but I tried to simplify the "you don't even need to sudo" behavior that I said that 9.10 exhibits, and now I can't get it to work the way I said it did in the previous post.
That said, I still can get it to behave the way that Ubuntu 8 did. System -> Administration -> Computer Janitor is what I used to trigger the sudo prompt that ultimately resulted in the privilege escalation.
Slashdot Mirror
Who cares about how it behaves on a larger data set? The point is that, if it weren't for the non-uniformity in the results, it'd be fine for what they have.
So, for practical values of "infinite loop", the probability is nonzero.
Yeah, but it's equally true that it's pretty clear that the probabilities of it going a while are very low. I mean, this guy did probably tens of thousands of tests; if there was even a half decent chance of one of them taking a while he'd have noticed.
Long story short:
- Not an infinite loop by a theoretical sense
- Not really an infinite loop by a practical sense
IMO that sort of stuff falls into the "crappy definition of 'can'". I can't think of any remotely reasonable implementation of Quicksort that would have that behavior.
If the random function by chance returns a value which calls for swapping two elements in the array in every pass, then the algorithm never ends.
The probability that happens is 0.
As the author of the article pointed out, this technique can cause an infinite loop.
For certain, pretty crappy definitions of "can". First, you'll notice he also points out that that "depends on the sorting algorithm used". I don't think that the most likely choices (Quicksort in particular) fall victim to this. Second, the other poster is right: the probability that it's actually an infinite loop is 0.
Is picking a worse random number generation function (the default one in C and JS) really fucking up?
There's no problem with the function they're using; the problem is how they're using it. If 'rand()' were perfect, their technique would still suck.
I can already see all the comments how MS would be favoring IE with this (summary conveniently left that one out), but as it is they're promoting the other browsers almost double more.
I do think the summary should have mentioned that bias, but I don't think it's quite as good a position as you convey. I bet the far right position is better than #3 and #4 at least.
(If I wanted to put on my conspiracy hat -- which I don't, I don't really believe this -- I'd say that MS wanted to bias it towards them and decided that biasing it toward #1 would be too blatant, but that #5 was "good enough".)
Given that each user is only going to see this screen once per computer, I'd say simply using the seconds of the current minute as a random seed should be OK
This problem has nothing to do with how the PRNG is seeded.
The word "seed" doesn't even appear in TFA at all.
Why not? Is the author suggesting that random functions in use today are somewhat deficient? What is his solution?
You know, it's really too bad that the author of the article the summary linked to didn't write up an article answering exactly that. Then maybe Slashdot could have linked to it.
(In a nutshell, the answers are, respectively: "because plopping a 'rand()' into your code doesn't mean that what you'll get out is uniform", "no", and "use a shuffling algorithm that works.")
they did of Party Poker's site.
Shit, PlanetPoker, not Party Poker. Sorry.
There were some folks a while ago who wrote up a security investigation they did of Party Poker's site.
One of the problems they had was a terrible, non-uniform shuffling algorithm. Completely different problem than what MS did, but interesting nonetheless. (I actually guessed that this is what MS did, but that's not the case.)
If you didn't know there was a law enforcement back door in everything Microsoft does, well, here's your proof.
Actually I would say that the documents indicate almost the opposite.
They'll give you information that MS has on the servers, but not information that's just on your XBox. To wit: 'Be aware that users may also store e-mail content on their computer's hard drive. Microsoft will not be able to disclose e-mail content stored on a user's computer --- only e-mail content stored on Microsoft's e-mail servers.' In other words, there isn't a backdoor onto the actual XBox.
Except it won't. You can't email a file that will run on a double-click -- unless your mail reader supports .desktop, the only file that allows things to execute without itself being executable.
Please read what I said. I said "And I still think you're deluding yourself if you think that adding 'just double click on the file and choose extract' in the email wouldn't catch a sizable population of people".
I guess I could have said "mail a TAR file" there too, but the point is that if you put those instructions in, the file you mail out wouldn't need to be executable.
I plan on putting together a demonstration of how I think this attack could play out, but it'll take a couple hours that I won't have for the next couple of days, so check back sometime over the weekend.
This is exactly the problem. No other kind of file, no matter what is in it, will run anything unless it has executable permission, so user can click on things until his mouse will wear out, and all he will see is viewers. ... Except now there is one exception to this rule -- .desktop, the only broken link in the chain of distrust.
To be fair:
- At least Ubuntu's configuration of Gnome asks for confirmation the first time you run a particular .desktop file, asking you if you want to add it to a trusted list, just run it, or do nothing. It's possible this is a new feature. So .desktop files aren't even as vulnerable as you think.
- Also, I don't see a .desktop file playing any role in my attack, except to the extent that it falls into the autorun folder; once there the exact protocol for how it's run (exec bit or no) is pretty irrelevant.
Running executable not installed by a package manager or a sysadmin, and not written by the user himself is something that no user should ever do on a non-Windows system.
On my system at work, I have a couple gigs of software I have installed to ~ because I don't have root.
I probably should check PGP signatures... but I don't.
(Just FYI, except for installers, there's barely more reason to run an executable on Windows than there is on Linux. And if you don't trust the installer, why do you trust the package from the package manager?)
It only happens because on Windows "Run" and "Open" are the same action in GUI...
I don't know if you noticed, but this is the same on Linux, at least with compiled executables. (I did notice that for scripts it asks if you want to open or run.) ...and almost everything is distributed as an executable. Even things that have no actual executable content are often in self-extracting archives.
Actually I'd say this doesn't matter all that much... half the time the virus uses the old "foo.jpg.exe" trick so that it doesn't even look like it's a program in the first place.
(Granted, this problem goes away somewhat on Linux.) ...any modern GUI will steer such user into a viewer and won't create an executable file unless user selects "Extract" option, then selects or makes a target directory.
And I still think you're deluding yourself if you think that adding "just double click on the file and choose extract" in the email wouldn't catch a sizable population of people if the world was instantly moved from Windows to Linux (if people were as proficient with Linux after the switch as they are with Windows now).
No, I would just make a special "interpreter" that takes existing .desktop format plus #! line and runs whatever is in "Exec" entry.
Oh, I think I may understand your beef with the .desktop files now: you can actually launch what's in the exec line by double clicking on it. Is that your problem?
If so, I somewhat see where you're coming from. I was only thinking of them as files that were read when Gnome logged on, so double clicking on them didn't enter the picture.
All GUI archive managers require a separate "Extract" command (that preserves execute permission), that is different from the default action that is to view a file (without giving it an execute permission even if it is present in the archive).
I have to admit I only tried "tar xvf" to verify that permissions were preserved. Nevertheless, you really think you couldn't get people to actually extract an archive?
For anyone but total newbies it should be obvious that the user should NEVER run anything he downloads unless he is installing some software that is not in a repository -- as root, as his own user or as anyone else.
Yeah, that users won't run crap is well justified.
And because I ran out of words in that sentence before links, here are some more: 1 2 .
To put those into context, those are all links from Wikipedia's "Timeline of Notable Computer Viruses and Worms" from the last decade, including the only two entries on that page from 2009 and 2010. Most of the above had a noticeable amount of mainstream press coverage at the time, and the list includes names like ILOVEYOU, Sobig, MyDoom, and Storm.
Sure, they aren't the scariest worms out there, and over the last few years they haven't been the most damaging. But at the same time, if I got to bet whether a manually-spread trojan is worthwhile, I know which side of that bet I'd take.
Personally I would just turn them into traditional #! scripts with "interpreter" doing what a file manager would, and file manager refusing to execute anything in them unless they are executable.
The .desktop files contain rather more information than just what program to run. How would you deal with that? Specially-formatted comments in the script? Pass the script a command line argument?
Besides, it's not like running scripts without execute permissions is a new concept. "source foo.sh", ". foo.sh", "perl foo.pl", "python foo.py", etc. IMO are all comparable to Gnome looking into the .desktop files on boot to see what to run.
Hmm, which attempt do you refer to? I've been accused of that a few times. (I stand by what I say BTW.)
Why do posts like this dissapear?
Huh? Posts like what?
It's just an attempt to spin the story against Microsoft, for no apparent reason
Did you miss "posted by kdawson"?
I don't know how it works everywhere else, but in the UK if there isn't significant indication that you shouldn't be somewhere then you aren't trespassing. Thus, an open doorway with a sign saying "No Entry" means you are trespassing if you go past it, but an open doorway is effectively an allowable entry point for the public.
What about a closed door?
Let me ask this. Let's say I put together a site with a login page. When I create the form, I have the choice between submitting the form as a GET or POST request. Should it make a difference as to whether someone trying passwords in the "password" field is "in the right"?
Suppose I make the (poor) decision to submit with GET. Is there a difference between someone using the form to guess passwords vs. seeing that the password is in the URL and just trying different things after "?password="?
Finally, let's say I change the submission script a bit so I use Javascript to redirect the user to "example.com/login/password" instead of "example.com/login?password=password". Is there a difference between those?
And at that point, what is the "attacker" doing that isn't just guessing a URL?
Somewhere in here there has to be a distinction between guessing someone's password and guessing a URL, but I have to admit that I don't quite see where it is. Is it the final difference, because you could expect someone to know that "?password=blah" indicates that it's supposed to be restricted? I dunno.
Don't want people reading your web site? Put it behind a login. Anything else is just sophistry to cover up incompetence.
While I do agree, and think that criminal investigations and such in this case are ludicrous and hope they don't go anywhere, part of me does wonder... what's the difference between a non-linked document where you don't tell people the URL and a site with a password?
Would guessing 3000 different passwords be as forgivable, even if the system doesn't cut you off? Is an easily-guessed URL any better than an easily-guessed password?
Having to chmod the .desktop files in .config/autostart wouldn't really change anything about my technique; you'd just have to add one more step to do chmod +x trojan.sh.desktop after creating that file. The thing the user runs to set all this up would have exactly zero difficulty doing this.
It assumes that there is a constantly-running hostile process, what means, pretty much everything that desktop environment does may be altered at that point.
Ah, but it doesn't mean it has to be. Often malware is better-off remaining unobtrusive so as not to draw attention.
Assuming that user did not run chmod +x on everything he downloads, this would require a completely separate exploit to happen before the user does anything privileged.
Oh stop with the BS. You and I won't run stuff that we download, but I guarantee if the place of Ubuntu and Windows were switched today, within a month you'd see Canonical push a security update that changes sudo's configuration, a sizable number of Ubuntu boxes rooted by this technique, or both.
Hell, all the malware writer would need to do is put things into a .tar.gz file and say "extract and run".
The difference is, this is the race against the user, not another process. Smart user will invalidate timestamps before doing anything that involves a non-administrative applications anyway...
Huh? What I gave a demonstration of requires no user action besides (1) running the user-local trojan (that would install itself in the startup apps) and (2) sometime, runing something that is started with sudo directly by gnome.
They do not have to run sudo then something non-privileged.
Ah, I think I see what was going on. It was keeping my credentials cached both (1) from one login to the next and (2) even though I was issuing 'sudo -k' and 'sudo -K' in an xterm.
I already said that sudo does some parent checking to make sure that two invocations don't reuse the same tokens if they don't share a parent; apparently -k/-K only removes the tokens that it would clash with.
So that mystery is solved; both versions have the same behavior in this respect (which shows why you don't need to be lucky to cache credentials).
BTW, on this general topic, I highly recommend this paper (PDF) from the Usenix security conference in 2005. The bottom line from it is if you say "eh, this is hard to exploit as you have to be unbelievably lucky", you definitely can't discount the chance that there's a way for the attacker to stack the dice in his favor.
I know I've already posted like a gagillion times, but I tried to simplify the "you don't even need to sudo" behavior that I said that 9.10 exhibits, and now I can't get it to work the way I said it did in the previous post.
That said, I still can get it to behave the way that Ubuntu 8 did. System -> Administration -> Computer Janitor is what I used to trigger the sudo prompt that ultimately resulted in the privilege escalation.