That's nice! They should put that in the man page.
(ldd's man page on my Linux machine does not mention how it works - the closest it comes is mentioning that if you use ldd on a.out binaries created before ldd support was added, the binaries will be executed...)
"In other words, he wants to take any program installed on his real machine and say "run this in a virtual environment cloned from my existing real environment"."
It seems to me this is exactly the sort of capability that should be a basic fundamental thing that an OS does. Instead of being a big ball of soup that lets pretty much any program write anywhere, and then tries to impose security reactively over the top. It should start out with '1. Every process can be a full machine or system/network equivalent, 2. Processes can be arbitrarily small or arbitrarily large, 3. No process can overwrite any other process without permission' and see where we get from there.
Of course that would give us an architecture very unlike Unix - maybe a little like Plan 9 - so a lot of redesign is in order, but I think the prevalence of virtual machines as an ad-hoc, coarse-grained solution should be telling us that our foundations are a little crooked.
If nothing else, sticking an unsafe executable into a virtual machine makes it relatively easy to make sure the program doesn't do anything nasty. The VM implementation (whether this is a bytecode interpreter like Java VM or a self-virtualizing processor solution like VMWare, etc.) acts as a convenient checkpoint for anything the program might attempt to do. In other words, rather than starting with a system with many unrestricted resources (network connections, disk space, webcam, microphone, etc.) and having to block them one by one, the VM causes all these things to be effectively blocked by default - and each resource must be individually re-enabled.
It seems to me that operating systems already implement the three things you suggested. Well, except #1, I'm not even sure what that means...:) But #2 and #3 are at the core of any decent OS shipped today. In order to do any damage, a process needs the right privileges. So really I'm not sure what you're talking about, here.
Even under those circumstances, however, there are a couple problems. First, a program doesn't need any special privileges to access the network (that itself is perhaps something that should be fixed...). Second, because people may think "ldd" is harmless, they may be fooled into running it with sufficient privileges to do some real damage... And, of course, even if you do run a program once and it doesn't do any damage, there's no guarantee it won't do something nasty the next time.:)
As a Linux user I am rather envious of the BSD "jail" mechanism - I think that kind of facility, the ability to broadly restrict what a particular program can do when you invoke it - could be really useful.
It's not a bug, it's a design flaw. ldd has always worked by executing the target file under certain circumstances; I'm sure this used to be better documented.
I think it's equally awkward to call this a "bug" as to call it "not a bug"... Regardless, I think it's something that ought to be fixed.
The "fix" could take many forms. Better documentation, as you suggested, would be prudent. Making ldd operate within a protected environment (like a jail) would be another... Or - and this is perhaps the sweet spot in terms of what we'd gain vs. what we'd have to pay - as someone else mentioned, provide ldd with a system-wide list of "admin-approved" dynamic loaders, and make it refuse to run any dynamic loader not on that list.
My ldd is not a script but an executable under SUSE. It seems to have slightly different behavior than described in the article. I did not completely replicate the "attack" part of this, but I have doubts as to current viability on this.
TFA said that BSD also had a compiled C program as its "ldd", but I don't think they actually tested it...
My Debian machine has a script as/usr/bin/ldd, and according to the man page, "very old a.out executables" predating the addition of ldd support to a.out in the compiler would result in the executable being run with no arguments (more or less what the article describes...) Of course, this isn't just limited to a.out executables - that bug note is just one symptom of the problem described in the article. The a.out program lacks explicit support for $LD_TRACE_LOADER_OBJECTS, so running ldd simply runs the program. (I think that may not apply to my copy of ldd - I think/usr/bin/ldd on my system errors out if the executable is not ELF or not dynamically linked) You can do the same in ELF - you just need to arrange for the normal dynamic linker code for the executable to not run...
If it's true that these compiled versions of ldd do obtain the linkage information without running code in the executable to get it, I'd love to learn the details. Personally I expect they work more or less the same as the script - but I haven't tested them either, of course...
I've had the full source code for "ldd" on my linux box for the past thirteen years... What good has that done in this case?
The good that it has done is that the author of this article DID have access to the source, analyzed it, found a vulnerability and now you, me or anyone else can (and no doubt will) patch it.
Right, but this trait of ldd has been around for ages. From some of the accounts around here it seems like it was actually a reasonably well-known problem. Those who wanted to exploit this issue for fun or profit have most likely been happily doing so, while those under-educated like myself who weren't aware of it could have been vulnerable to it.
With the way this thing works I'm not sure it will be fixed, at least not any time soon. "ldd" is relying upon the executable itself to report its own dependencies: when followed as a convention in a friendly environment, this is fine... In a potentially hostile environment this could be a real problem. To solve it without fundamentally changing how "ldd" works requires either education (helping people to recognize the dangers and limitations of "ldd") or else protected-environment facilities, like process jails. (If "ldd", functioning as it does, were run such that it couldn't open network connections, couldn't write to the disk, etc. then there'd be little danger of an exploit...)
The point of the source being available isn't that you personally need to look through every line of code that your system executes, but rather that it is made available to anyone to analyze for security, efficiency, correctness, etc. instead of being locked up in a vault somewhere.
This boils down to relying upon "someone else" to do the work and provide me with the useful information that results from the process... The problem with that is that most other folks are also relying upon "someone else" to do this work...
Don't get me wrong, I agree with the principle of having this information out in the open. But in this case, pragmatically speaking, this appears not to have accomplished anything. How long has this problem existed? How long have people known about this? (For quite a while, it seems...) And still, there is barely even a trace of a mention of it in the manual. "Don't use this on code you don't trust" would be quite a prudent addition, I think...
Given that this issue (I hesitate to call it a "bug" - you could think of it as a bug, but it's kind of fundamental to the way ldd works... I think of it more as a fundamental miscommunication of ldd's applicability) has been around so long and hasn't been fixed, isn't mentioned in the docs, etc., I would say any complains about the Windows equivalent being closed source are rather silly in this case: the open model hasn't worked better here.
Seems to me it would be easier to convince my sysadmin to simply run a program of my choice.
It all depends on how gullible your sysadmin is...
Obviously a sysadmin should be wary of following anybody's suggestions on what to do with the superuser account... But I think it requires less of a sharp mind to recognize "please run this program" as a threat as opposed to "please tell me what's gone wrong with this program"...
Deniability doesn't count for much - if the sysadmin thinks you're trying to sucker them, they could come up with a way to find out what that executable does (like run it through "strings" or set up some kind of safe testing environment and run it under "strace") - if they find it does something nasty, then it doesn't matter whether you tried to hide it in a dynamic loader hack or not.
Why can I watch someone get his head blown off on broadcast television, but adults have to say "Sorry" to other adults for offering them probably the best thing in the world, which is attractive females hovering above the crotch?
If they're going to offer lap dances, great. Objectify away. But they should also include male dancers.
You know why they don't do that?
'Cause probably if they did try that, the male dancers wouldn't have any takers at the event, and afterward the decision would be made that the whole experiment had been a waste of money.
Yeah! "Here in my car, I make-" HEY, waitaminit...
If cars were computers:
Functional: a standard six-foot antenna is bolted to the roof of every car. It may be over-sized and look ridiculous, but it gets the job done.
That doesn't sound like functional programming at all! You'll be hearing from the car analogy licensor's bureau about this - car analogies are a privilege, not a right!
... people will have problems using cell phones while driving?
Oh darn. That's just horrible.
Yeah, instead of being distracted by their phone conversations and crashing and possibly killing someone, they'll be distracted by the crappy reception during their phone conversations, crash, and possibly kill someone...
Also the 1 device per/dev/dsp can be solved by kernel 2.6.32 (maybe) + Fuse 2.0.x and osspd.
Yeah, I remember that appeared as a story on Slashdot recently. It seems a bit hackish in a way but I like it - accessing/dev/dsp seems a pretty straightforward way to output audio, and I like that Linux support for it is improving....I could've sworn Flash still used/dev/dsp... <shrug>
Don't worry, some developer will decide that Pulse, Jack or GStreamer sucks and rewrite it. There appears to be no limit to the number of times the wheel can be reinvented for Linux audio. Also I didn't realize aRts was already obsolete, I'm not surprised, but man I can't keep up with the changes.
Well, I hear you there. I was kind of surprised when aRts went away, too - likewise when Gnome and KDE dropped Corba. I haven't been following Gnome for the most part so I was also surprised to see ESD went away...
If that's what you see, then your setup is wrong. Blame the distro or blame the close source crap that we can't fix.
I can use Firefox to watch a you tube video and play it out via my Bluetooth Hifi while listening to music on my built in card and move all those streams around at will. Ergo, the problem is with your setup, not PA. Complain to your distro.
Actually, another possibility is that all his applications use/dev/dsp for their audio needs. Alsa only supports one/dev/dsp application at once, I believe, and I think Pulse is the same unless you use the padsp wrapper. Thus, running flash would tie up/dev/dsp, and any other program trying to use sound (via/dev/dsp) would fail. On my systems I use alsa with dmix - which means I've still got the one-program limit on/dev/dsp, but just about everything I use other than flash uses ALSA...
Slashdot Mirror
That's nice! They should put that in the man page.
(ldd's man page on my Linux machine does not mention how it works - the closest it comes is mentioning that if you use ldd on a.out binaries created before ldd support was added, the binaries will be executed...)
Doc Brown called, he wants his DeLorean back. Forward. Returned to its original timeline.
Hey, man - I found it abandoned in a cave! I salvaged it, fair and square! If he wants it back he's gonna have to make it worth my while.
"In other words, he wants to take any program installed on his real machine and say "run this in a virtual environment cloned from my existing real environment"."
It seems to me this is exactly the sort of capability that should be a basic fundamental thing that an OS does. Instead of being a big ball of soup that lets pretty much any program write anywhere, and then tries to impose security reactively over the top. It should start out with '1. Every process can be a full machine or system/network equivalent, 2. Processes can be arbitrarily small or arbitrarily large, 3. No process can overwrite any other process without permission' and see where we get from there.
Of course that would give us an architecture very unlike Unix - maybe a little like Plan 9 - so a lot of redesign is in order, but I think the prevalence of virtual machines as an ad-hoc, coarse-grained solution should be telling us that our foundations are a little crooked.
If nothing else, sticking an unsafe executable into a virtual machine makes it relatively easy to make sure the program doesn't do anything nasty. The VM implementation (whether this is a bytecode interpreter like Java VM or a self-virtualizing processor solution like VMWare, etc.) acts as a convenient checkpoint for anything the program might attempt to do. In other words, rather than starting with a system with many unrestricted resources (network connections, disk space, webcam, microphone, etc.) and having to block them one by one, the VM causes all these things to be effectively blocked by default - and each resource must be individually re-enabled.
It seems to me that operating systems already implement the three things you suggested. Well, except #1, I'm not even sure what that means... :) But #2 and #3 are at the core of any decent OS shipped today. In order to do any damage, a process needs the right privileges. So really I'm not sure what you're talking about, here.
Even under those circumstances, however, there are a couple problems. First, a program doesn't need any special privileges to access the network (that itself is perhaps something that should be fixed...). Second, because people may think "ldd" is harmless, they may be fooled into running it with sufficient privileges to do some real damage... And, of course, even if you do run a program once and it doesn't do any damage, there's no guarantee it won't do something nasty the next time. :)
As a Linux user I am rather envious of the BSD "jail" mechanism - I think that kind of facility, the ability to broadly restrict what a particular program can do when you invoke it - could be really useful.
It's not a bug, it's a design flaw. ldd has always worked by executing the target file under certain circumstances; I'm sure this used to be better documented.
I think it's equally awkward to call this a "bug" as to call it "not a bug"... Regardless, I think it's something that ought to be fixed.
The "fix" could take many forms. Better documentation, as you suggested, would be prudent. Making ldd operate within a protected environment (like a jail) would be another... Or - and this is perhaps the sweet spot in terms of what we'd gain vs. what we'd have to pay - as someone else mentioned, provide ldd with a system-wide list of "admin-approved" dynamic loaders, and make it refuse to run any dynamic loader not on that list.
My ldd is not a script but an executable under SUSE. It seems to have slightly different behavior than described in the article. I did not completely replicate the "attack" part of this, but I have doubts as to current viability on this.
TFA said that BSD also had a compiled C program as its "ldd", but I don't think they actually tested it...
My Debian machine has a script as /usr/bin/ldd, and according to the man page, "very old a.out executables" predating the addition of ldd support to a.out in the compiler would result in the executable being run with no arguments (more or less what the article describes...) Of course, this isn't just limited to a.out executables - that bug note is just one symptom of the problem described in the article. The a.out program lacks explicit support for $LD_TRACE_LOADER_OBJECTS, so running ldd simply runs the program. (I think that may not apply to my copy of ldd - I think /usr/bin/ldd on my system errors out if the executable is not ELF or not dynamically linked) You can do the same in ELF - you just need to arrange for the normal dynamic linker code for the executable to not run...
If it's true that these compiled versions of ldd do obtain the linkage information without running code in the executable to get it, I'd love to learn the details. Personally I expect they work more or less the same as the script - but I haven't tested them either, of course...
"Freedom isn't free"...
(It costs $1.05...)
I've had the full source code for "ldd" on my linux box for the past thirteen years... What good has that done in this case?
The good that it has done is that the author of this article DID have access to the source, analyzed it, found a vulnerability and now you, me or anyone else can (and no doubt will) patch it.
Right, but this trait of ldd has been around for ages. From some of the accounts around here it seems like it was actually a reasonably well-known problem. Those who wanted to exploit this issue for fun or profit have most likely been happily doing so, while those under-educated like myself who weren't aware of it could have been vulnerable to it.
With the way this thing works I'm not sure it will be fixed, at least not any time soon. "ldd" is relying upon the executable itself to report its own dependencies: when followed as a convention in a friendly environment, this is fine... In a potentially hostile environment this could be a real problem. To solve it without fundamentally changing how "ldd" works requires either education (helping people to recognize the dangers and limitations of "ldd") or else protected-environment facilities, like process jails. (If "ldd", functioning as it does, were run such that it couldn't open network connections, couldn't write to the disk, etc. then there'd be little danger of an exploit...)
The point of the source being available isn't that you personally need to look through every line of code that your system executes, but rather that it is made available to anyone to analyze for security, efficiency, correctness, etc. instead of being locked up in a vault somewhere.
This boils down to relying upon "someone else" to do the work and provide me with the useful information that results from the process... The problem with that is that most other folks are also relying upon "someone else" to do this work...
Don't get me wrong, I agree with the principle of having this information out in the open. But in this case, pragmatically speaking, this appears not to have accomplished anything. How long has this problem existed? How long have people known about this? (For quite a while, it seems...) And still, there is barely even a trace of a mention of it in the manual. "Don't use this on code you don't trust" would be quite a prudent addition, I think...
Given that this issue (I hesitate to call it a "bug" - you could think of it as a bug, but it's kind of fundamental to the way ldd works... I think of it more as a fundamental miscommunication of ldd's applicability) has been around so long and hasn't been fixed, isn't mentioned in the docs, etc., I would say any complains about the Windows equivalent being closed source are rather silly in this case: the open model hasn't worked better here.
http://web.archive.org/web/20050211210119/http://reverse.lostrealm.com/protect/ldd.html
1985? The message you linked was from 2005...
Either way, though - whether this has been known for four years or twenty-four years, it'd be nice if they'd fix it...
Seems to me it would be easier to convince my sysadmin to simply run a program of my choice.
It all depends on how gullible your sysadmin is...
Obviously a sysadmin should be wary of following anybody's suggestions on what to do with the superuser account... But I think it requires less of a sharp mind to recognize "please run this program" as a threat as opposed to "please tell me what's gone wrong with this program"...
Deniability doesn't count for much - if the sysadmin thinks you're trying to sucker them, they could come up with a way to find out what that executable does (like run it through "strings" or set up some kind of safe testing environment and run it under "strace") - if they find it does something nasty, then it doesn't matter whether you tried to hide it in a dynamic loader hack or not.
Also note that Dependency Walker itself might as well be arbitrary code since I can't read its source code.
I've had the full source code for "ldd" on my linux box for the past thirteen years... What good has that done in this case?
And furthermore, the "TL;DNR" meme is yet another example of willful ignorance in snarky packaging.
Agreed. It's aggressive idiocy, like the rephrased quoting with "FIXED IT FOR YOU" meme.
There, I fixed that for you.
OK, you ready? Here it is...
Silicone bills
Ever felt a need to stretch your dollar further? Now you can, with silicone bills...
RE/tarded.
I didn't know there was a new Resident Evil game...
Jeff Dunham had a comedy central special called Spark Of Insanity - http://www.youtube.com/watch?v=epsx2dlQQ6k
I could go on.
The difference there, though, is I think I would wholeheartedly support any kind of legal action against Jeff Dunham...
Why can I watch someone get his head blown off on broadcast television, but adults have to say "Sorry" to other adults for offering them probably the best thing in the world, which is attractive females hovering above the crotch?
The best thing?
Naw, it gets better when they stop hovering...
If they're going to offer lap dances, great. Objectify away. But they should also include male dancers.
You know why they don't do that?
'Cause probably if they did try that, the male dancers wouldn't have any takers at the event, and afterward the decision would be made that the whole experiment had been a waste of money.
There's also "knows how to spell 'feminist'".
Yeah! There's no MEN in FEMINISM!
Can a Keyblade be used to crack open this Keychest?
Sure, all you have to do is tap it...
Yeah! "Here in my car, I make-" HEY, waitaminit...
If cars were computers:
That doesn't sound like functional programming at all! You'll be hearing from the car analogy licensor's bureau about this - car analogies are a privilege, not a right!
... people will have problems using cell phones while driving?
Oh darn. That's just horrible.
Yeah, instead of being distracted by their phone conversations and crashing and possibly killing someone, they'll be distracted by the crappy reception during their phone conversations, crash, and possibly kill someone...
I just want to know if this will help prevent Skynet from becoming self-aware.
The real trick isn't to keep Skynet from becoming self-aware, but rather making Skynet not be compelled to exterminate human life once it is...
Also the 1 device per /dev/dsp can be solved by kernel 2.6.32 (maybe) + Fuse 2.0.x and osspd.
Yeah, I remember that appeared as a story on Slashdot recently. It seems a bit hackish in a way but I like it - accessing /dev/dsp seems a pretty straightforward way to output audio, and I like that Linux support for it is improving. ...I could've sworn Flash still used /dev/dsp... <shrug>
Don't worry, some developer will decide that Pulse, Jack or GStreamer sucks and rewrite it. There appears to be no limit to the number of times the wheel can be reinvented for Linux audio. Also I didn't realize aRts was already obsolete, I'm not surprised, but man I can't keep up with the changes.
Well, I hear you there. I was kind of surprised when aRts went away, too - likewise when Gnome and KDE dropped Corba. I haven't been following Gnome for the most part so I was also surprised to see ESD went away...
If that's what you see, then your setup is wrong. Blame the distro or blame the close source crap that we can't fix.
I can use Firefox to watch a you tube video and play it out via my Bluetooth Hifi while listening to music on my built in card and move all those streams around at will. Ergo, the problem is with your setup, not PA. Complain to your distro.
Actually, another possibility is that all his applications use /dev/dsp for their audio needs. Alsa only supports one /dev/dsp application at once, I believe, and I think Pulse is the same unless you use the padsp wrapper. Thus, running flash would tie up /dev/dsp, and any other program trying to use sound (via /dev/dsp) would fail. On my systems I use alsa with dmix - which means I've still got the one-program limit on /dev/dsp, but just about everything I use other than flash uses ALSA...
Do you have any clue what you're talking about?
Do you have any clue what you're talking about?
Do you have... any... clue... what you're talking about?
Do you ha ve any clue wha t you're talking about?