Saying that British Telecom is pants isn't really news. Moaning about them has been part of life in Britain for the last twenty five years, and frankly if this even changed many of us would no longer know what to do all day.
"Damn and blast British Telecom" exclaimed Dirk, the words coming easily from force of habit.
I found the thread, it's at http://lists.freedesktop.org/archives/xdg/2005-Mar ch/006224.html. I unsubscribed in disgust shortly afterwards. IMHO this is pretty damn serious, but nothing's been done about it, in favour of waiting for SELinux to be integrated into desktop distributions. Maybe that will be a sensible solution in about 15 years...
If you're talking about the.desktop file vulnerabilities, you're right. It was discussed a while ago on xdg-list, but it seems no one important enough at freedesktop.org thought it was worthwhile fixing the specification. Idiots!
It depends whether the nsIFile class allows you to create a file with execute permissions. If it doesn't, then no--it is not possible, at least by creating an nsIFile, containing a shell script, and calling nsIFile::launch().
And, as someone else pointed out, the site trying to exploit you does need to be in your whitelist for the exploit to work. So I guess we can delete this entire thread!;)
> Thank you oh great hair splitter for that nonpoint.
You know, if you don't understand the finer points of a discussion about security measures, you shouldn't open your mouth.
> The commands in the script can be executed without the execute bit, and that's > what matters.
No they can't.
Mozilla is able to create a file, containing harmful commands, with the correct #! header. Fine. However, if you actually read the exploit code, you will see that the call to file.launch() will fail. This is because the file doesn't have the execute permission!
On Windows, of course, whether a file can be executed is determined by the file's name--a rather moronic system if you ask me, but you don't need to--you merely need to look at the constant waves of epidemics striking users of that platform.
"Sophos reported earlier this week that Sober.P appears to turn off Symantec's antivirus protection and the Microsoft Windows XP firewall, probably as a way of preparing computers to distribute spam and to spread itself wider."
This wouldn't be possible if people didn't read their goddamn email as an administrator!
Also, "[the worm] is currently pushing nearly 25% of all email traffic at the moment"? Who needs Editors anyway?
> There is no significant difference between running "./filename" which contains a > #!/bin/bash header and execute permission or running "sh filename" without.
Now this is true, but the script is not being executed. The file specified in the #! header is the one that is being executed. When you try to exec() a script, the kernel sees the #! header, and executes whatever program it finds there, with the path to the script as the first argument.
The program actually being executed doesn't have to do anything with its arguments, though of course it normally does, otherwise there's not much point putting it in a #! line.:)
For example, here's how to create the cheapest quine of all time:
Many thanks. This should really be off by default.
Or even better, add a 'this domain name was not found. did you mean: x, y, z' section to the XUL error page (once they get XUL error pages working well enough to be enabled by default).
Unfortunately, the exploit could have just as easily created a file starting with #!/bin/sh, and passed 555 as the 'permissions' argument to createUnique.
Why on earth the browser thinks it's necessary to allow scripts to create executeable files is beyond me.
You're probably correct there. I make a point of telling all the people I install it for that they must update whenever the red circle appears. It would be better if Firefox itself placed some text beside it such as "Critical updates available--click here to protect your computer".
As the temperature of the water is gradually increased, the frog will eventually become more and more active in attempts to escape the heated water. If the container size and opening allow the frog to jump out, it will do so.
It sounds like these researchers are lucky the animal rights loonies haven't burned down their houses, in order to see whether they could get out in time.
Saying that British Telecom is pants isn't really news. Moaning about them has been part of life in Britain for the last twenty five years, and frankly if this even changed many of us would no longer know what to do all day.
"Damn and blast British Telecom" exclaimed Dirk, the words coming easily from force of habit.
I found the thread, it's at http://lists.freedesktop.org/archives/xdg/2005-Mar ch/006224.html. I unsubscribed in disgust shortly afterwards. IMHO this is pretty damn serious, but nothing's been done about it, in favour of waiting for SELinux to be integrated into desktop distributions. Maybe that will be a sensible solution in about 15 years...
Doh! Nasty.
.desktop file vulnerabilities, you're right. It was discussed a while ago on xdg-list, but it seems no one important enough at freedesktop.org thought it was worthwhile fixing the specification. Idiots!
If you're talking about the
Didn't mIcq get trojaned a few years ago?
And I remember that Linux had a bad patch a while ago that changed a test into an assignment (the test was whether a process had uid 0... oops).
That said, you are correct: the barrier is far higher. I know the Linux incident was caught before any releases were made containing the bad code.
It depends whether the nsIFile class allows you to create a file with execute permissions. If it doesn't, then no--it is not possible, at least by creating an nsIFile, containing a shell script, and calling nsIFile::launch().
Even better.
;)
And, as someone else pointed out, the site trying to exploit you does need to be in your whitelist for the exploit to work. So I guess we can delete this entire thread!
Could you please give details on the APIs that Mozilla exposes to web pages to allow them to launch arbitary commands?
The entire thing is only an issue because of Windows' braindead filename = filetype = ability to execute system.
> Thank you oh great hair splitter for that nonpoint.
You know, if you don't understand the finer points of a discussion about security measures, you shouldn't open your mouth.
> The commands in the script can be executed without the execute bit, and that's
> what matters.
No they can't.
Mozilla is able to create a file, containing harmful commands, with the correct #! header. Fine. However, if you actually read the exploit code, you will see that the call to file.launch() will fail. This is because the file doesn't have the execute permission!
On Windows, of course, whether a file can be executed is determined by the file's name--a rather moronic system if you ask me, but you don't need to--you merely need to look at the constant waves of epidemics striking users of that platform.
And hence, the browser has to create the file...? :)
"Sophos reported earlier this week that Sober.P appears to turn off Symantec's antivirus protection and the Microsoft Windows XP firewall, probably as a way of preparing computers to distribute spam and to spread itself wider."
This wouldn't be possible if people didn't read their goddamn email as an administrator!
Also, "[the worm] is currently pushing nearly 25% of all email traffic at the moment"? Who needs Editors anyway?
> #!/bin/bash header and execute permission or running "sh filename" without.
Now this is true, but the script is not being executed. The file specified in the #! header is the one that is being executed. When you try to exec() a script, the kernel sees the #! header, and executes whatever program it finds there, with the path to the script as the first argument.
The program actually being executed doesn't have to do anything with its arguments, though of course it normally does, otherwise there's not much point putting it in a #! line.
For example, here's how to create the cheapest quine of all time:
Well, in Windows it would only have administrator priviliges if the user was dumb enough to run Firefox as an administrator. ;)
Many thanks. This should really be off by default.
Or even better, add a 'this domain name was not found. did you mean: x, y, z' section to the XUL error page (once they get XUL error pages working well enough to be enabled by default).
Did MS even bother to fix the scroll bar drag/drop exploit? Remote code execution... tasty.
If you had been more polite, I might have had some suggestions. But since you weren't, please fuck off to google.com.
Unfortunately, the exploit could have just as easily created a file starting with #!/bin/sh, and passed 555 as the 'permissions' argument to createUnique.
Why on earth the browser thinks it's necessary to allow scripts to create executeable files is beyond me.
> Why would anyone run routinely with "Allow web sites to install
> software" enabled?
1. It's on by default
2. We naievely assumed that the whitelist of web sites allowed to install software did its damn job.
You're probably correct there. I make a point of telling all the people I install it for that they must update whenever the red circle appears. It would be better if Firefox itself placed some text beside it such as "Critical updates available--click here to protect your computer".
Incorrect. You are executing sh, which is doing its own thing in interpreting the file 'filename'.
Attempting to execute 'filename' directly will yield 'permission denied'.
The user doesn't need to. Firefox polls for updates every so often all by itself.
Can this behaviour be disabled in Mozilla?
Ah yes, the British version of "Love it or leave it!". What are you, Ruth Kelly?
Here's the best bit:
As the temperature of the water is gradually increased, the frog will eventually become more and more active in attempts to escape the heated water. If the container size and opening allow the frog to jump out, it will do so.
It sounds like these researchers are lucky the animal rights loonies haven't burned down their houses, in order to see whether they could get out in time.
> restrict what use can be made of information gained in this way. Make it
> inadmissible as evidence in court, for example.
This only works as long as trials are public, and defendants (and their counsel) are allowed to see the evidence against them.
This is always a fun argument. ;)
The word you're looking for is "plagiariser" or "plagiarizer" probably if you hail from the far side of the pond.