I found my first local-root exploit in 1978. I've been doing this longer than a lot of security "experts" have been alive.
Just about every local root bug is caused by a bug in a setuid program, and the rest are caused by bugs in programs that were already running as root. The options are (a) the shell (restricted or otherwise) that you're running telnetd from is already running as root, or (b) telnetd or a program it launches is setuid. There's no third option. The kernel and device drivers (like ptys) don't spontaneously cause non-root programs to start running as root.
The third option is "something between telnetd and the kernel is broken - non-root users are able to do things that only root users should be able to do".
That is about as likely as the spontaneous generation of trout in milk.
That option is far less likely than the option that the original shell was running as root all along and has some application level tweaks to try and keep people from knowing that they were already in a root shell.
Either telnetd or something it's running is setuid when it shouldn't be, or the original shell is really running as root.
Either way, it asks you if you want to try it twice, and then leaves you alone.
The fact that it redirects your connection even once is completely indefensible, no matter what the download is called. I can't believe anyone's defending this kind of slimeball tactic.
The idea that a router should even include a mechanism to hijack connections is just wrong. No excuses. That shouldn't have even been considered in the first place. That they went ahead and shipped it is batshit crazy.
If you're not interested in using Microsoft's APIs, then why are you accepting the 2x to 5x overhead of CIL over native code? There's nothing magic about.net/mono, and now there's effectively only one ISA left you might as well write your code in any language that compiles to x86 and calls glibc... except that you want to talk to databases and other higher level services. Which is where the lockin is.
I am also concerned about the total reliance on one big honker parachute, and wonder what the vehicle's speed will be (slowed by pure air drag alone?) when that main has to deploy.
Watch the video, there's three drogues before the main cute is popped.
This agreement is being pushed through in secret: there's no general support for this kind of treaty in the USA, in fact it sounds like a good deal of it is against the US constitution. If Australia or Brazil was the most powerful country in the world, the people who want these kind of controls would be spending their efforts to coopt and corrupt their governments instead.
I like the term "freedom proof fence" but it doesn't seem to be in general use... looks like someone tried a bit of low-level astroturfing and got it temporarily into Wikipedia and a couple of twitters, but that's it.
When you boil everything down, nothing is counter-intuitive
Except quantum physics, voting paradoxes, and why the guy in the car in front of you doesn't close the gap in front of him before... oh god, there he goes again, let some jerk driving down the breakdown lane sneak in front of him. I tell you, some people...
When you think about it, GFDL means authors can't get improvements back, too...
As the author, you can release your work under multiple licenses. For example, you can release one version under GFDL, another under CC-BY-SA, and a third under a non-transferrable license similar to the way TrollTech dual-licenses Qt.
Any improvements anyone does to any of these versions of the work can't be reincorporated back into your own work, and you are restricted in how you can re-use it. That's a straightforward and unavoidable result of the way mandatory-permission licenses work. If you don't like that, use a discretionary-permission license like the BSDL or MIT license.
Studying a stego-channel in this way leads to some counter-intuitive results: for example, in certain circumstances, doubling the number of algorithms looking for hidden data can increase the capacity of the steganographic channel"
That's not what the paper claims. It claims that when there are multiple detectors, adding noise to the channel between the two detectors can increase the available bandwidth. This isn't really all that counter-intuitive when you think about it.
Microsoft has over a decade's track record of giving short shift to security in favor of performance. Like Java, they are using components implemented in the interpreted code to implement the security model, rather than implement a guaranteed closed interpreter that has no mechanisms to do dangerous actions. The main difference is that Sun had a decent security track record - where they had security problems, they closed them completely - and took the course of sticking to compatibility and security over trying to stay on the bleeding edge in performance (and Microsoft took advantage of that to push their horridly risky ActiveX technology).
I don't trust ANYTHING Microsoft does to be secure. They are still pushing "security theatre" solutions like UAC and the leaky sandbox around IE instead of breaking with inherently insecure APIs.
People have claimed that they're going to be different this time. I've been hearing that for a decade, and it's never happened before. What's different this time?
No, it's called a "box cutter". Scissors are a pain to open much of this kind of packaging with because of the bevelled edges. Even if they're Fiskars.
Slashdot Mirror
I found my first local-root exploit in 1978. I've been doing this longer than a lot of security "experts" have been alive.
Just about every local root bug is caused by a bug in a setuid program, and the rest are caused by bugs in programs that were already running as root. The options are (a) the shell (restricted or otherwise) that you're running telnetd from is already running as root, or (b) telnetd or a program it launches is setuid. There's no third option. The kernel and device drivers (like ptys) don't spontaneously cause non-root programs to start running as root.
The third option is "something between telnetd and the kernel is broken - non-root users are able to do things that only root users should be able to do".
That is about as likely as the spontaneous generation of trout in milk.
That option is far less likely than the option that the original shell was running as root all along and has some application level tweaks to try and keep people from knowing that they were already in a root shell.
Either telnetd or something it's running is setuid when it shouldn't be, or the original shell is really running as root.
Either way, it asks you if you want to try it twice, and then leaves you alone.
The fact that it redirects your connection even once is completely indefensible, no matter what the download is called. I can't believe anyone's defending this kind of slimeball tactic.
The idea that a router should even include a mechanism to hijack connections is just wrong. No excuses. That shouldn't have even been considered in the first place. That they went ahead and shipped it is batshit crazy.
The fact that they even considered doing this, let alone the fact that they actually did it, is just stark raving nutso.
If you run telnetd from a non-root account, telnetd will NEVER, NOHOW, give you root, unless it's setuid. Period.
If telnetd gets you root, then either telnetd is setuid root, or you already were running as root in the shell you started telnetd from.
There is no third option. "Neither" isn't a possible answer.
If you're not interested in using Microsoft's APIs, then why are you accepting the 2x to 5x overhead of CIL over native code? There's nothing magic about .net/mono, and now there's effectively only one ISA left you might as well write your code in any language that compiles to x86 and calls glibc... except that you want to talk to databases and other higher level services. Which is where the lockin is.
Does this mean that telnetd is setuid root, or does it mean that you already have to have root to get root?
I am also concerned about the total reliance on one big honker parachute, and wonder what the vehicle's speed will be (slowed by pure air drag alone?) when that main has to deploy.
Watch the video, there's three drogues before the main cute is popped.
So that means it's thread safe?
I hope so, given all the threads in all those drogue chutes before they deploy the main chute.
This agreement is being pushed through in secret: there's no general support for this kind of treaty in the USA, in fact it sounds like a good deal of it is against the US constitution. If Australia or Brazil was the most powerful country in the world, the people who want these kind of controls would be spending their efforts to coopt and corrupt their governments instead.
I like the term "freedom proof fence" but it doesn't seem to be in general use... looks like someone tried a bit of low-level astroturfing and got it temporarily into Wikipedia and a couple of twitters, but that's it.
You're in a balloon.
When you boil everything down, nothing is counter-intuitive
Except quantum physics, voting paradoxes, and why the guy in the car in front of you doesn't close the gap in front of him before... oh god, there he goes again, let some jerk driving down the breakdown lane sneak in front of him. I tell you, some people...
When you think about it, GFDL means authors can't get improvements back, too...
As the author, you can release your work under multiple licenses. For example, you can release one version under GFDL, another under CC-BY-SA, and a third under a non-transferrable license similar to the way TrollTech dual-licenses Qt.
Any improvements anyone does to any of these versions of the work can't be reincorporated back into your own work, and you are restricted in how you can re-use it. That's a straightforward and unavoidable result of the way mandatory-permission licenses work. If you don't like that, use a discretionary-permission license like the BSDL or MIT license.
Studying a stego-channel in this way leads to some counter-intuitive results: for example, in certain circumstances, doubling the number of algorithms looking for hidden data can increase the capacity of the steganographic channel"
That's not what the paper claims. It claims that when there are multiple detectors, adding noise to the channel between the two detectors can increase the available bandwidth. This isn't really all that counter-intuitive when you think about it.
Microsoft has over a decade's track record of giving short shift to security in favor of performance. Like Java, they are using components implemented in the interpreted code to implement the security model, rather than implement a guaranteed closed interpreter that has no mechanisms to do dangerous actions. The main difference is that Sun had a decent security track record - where they had security problems, they closed them completely - and took the course of sticking to compatibility and security over trying to stay on the bleeding edge in performance (and Microsoft took advantage of that to push their horridly risky ActiveX technology).
I don't trust ANYTHING Microsoft does to be secure. They are still pushing "security theatre" solutions like UAC and the leaky sandbox around IE instead of breaking with inherently insecure APIs.
People have claimed that they're going to be different this time. I've been hearing that for a decade, and it's never happened before. What's different this time?
Your G4 is already out because it's not intel based.
(if anyone has a scan of the original, published in Asimov's back in the '70s, I'd appreciate it)
Can you run .NET or functional equivalent server side?
Being able to run CIL isn't the same as being able to provide all the libraries involved in Microsoft's APIs.
Otherwise Wine would have been trivial to implement.
I can't help but wonder where they are all being produced.
Taiwan, Korea, China, West Virginia, just like everything else.
O HAI! I UPGRADED UR PHYSICS
Just LOOK at the damn samples.
That test has already failed on Earth, at least on "fossils" that turned out to be inorganic.
What about the fact that life is pretty much a series of unusual chemical reactions? ;-)
Way to give away the surprising twist at the end.
No, it's called a "box cutter". Scissors are a pain to open much of this kind of packaging with because of the bevelled edges. Even if they're Fiskars.