Yes I am fairly sure Mac OS X has nothing to do with NetBSD:-)
At OSX's core is a Mach microkernel with a 4.4BSD personality, and the libraries are based mostly from FreeBSD (from version 3.4 I believe, please correct me if I'm wrong here) and NEXTSTEP.
The only similarity between Mac OS X and NetBSD is the 4.4BSD'ishness of it all, but FreeBSD has that too. They did base it off of BSD because Next was based on 4.3BSD personality Mach microkernel.
ssh had a bug, it was only relevant if you used your system's login (which it doesn't by default, but you _can_ opt for that). Which can be handy if you use a non-standard login(1).
> (notice the GAPING HOLE in Solaris/AIX [slashdot.org] systems that still isn't patched? Why aren't you going off on that?)
It wasn't just AIX/Solaris, it was also a ssh bug, which affected other platforms as well.
I'm not really much of an MS basher (I don't use their products, but that's just my choice), but bugs are bugs. Bugs happen. And you have to admit that/. (it's authors and much of the readership) is a bit biased when it comes to MS:-)
Heh, I did some extra reading and it's indeed promising, albeit difficult to implement. The act of observation disturbs the exchange, hence, whatever you intercept, its never the right "key".
Nifty... But it's still somewhat volatile and a lot can disturb it. I still doubt this can reliably be done in a "real world" environment
Timestamps have one fundamental problem: they are predictable. It might stop a replay attack, but not cryptoanalysis.
But just a thought, if attempts are made to make the signal "undetectable", isn't that falling into the 'security through obscurity' trap?
I find the assumption of "unbreakable crypto" a bit overzealous. Every crypto scheme can be cracked, only the time you have to invest in it seems to keep growing, and things seem to get more and more complex. The reason people feel save with high grade conventional crypto (thru PKI or be it symmetrical) is that it takes a *very* long time (as in hopefully centuries) to recover the message.
AFAIK, there is only one scheme that comes close to perfect, and that's the one time pad using a (dare I say) random "key" (say, a CD-R recorded with just white noise picked up from radio traffic or stellar background noise). If the "key" is handled in a secure manner, it's virtually unbeatable. Of course there is one VERY weak factor here, and that's the human factor, but still... Oh ironic is that the one time pad system is also the most simple one:-)
number three is not really something I directly agree with. Why? Because you end up with n to the power of n implementations of [insert unsafe library call], which is BAD (tm). Another problem is buffers of which the size is not exactly known, these have to be malloc()'ed or allocated otherwise.
You are also forgetting that there are other ways to skin that cat. Rewriting functions, returning into libc or rewriting GOT entries are another way to wreak havoc.
There's only one thing that really works: Code Reviews. Heck, programmers are human, they can slip up and make mistakes, even if they are the most careful coders in the world (they are still human). More eyeballs catch more bugs. And the next random person can spot a problem in five minutes that you are trying for days to prevent.
Bugs happen. Deal with it. The advantage that we open source people have is that our code is open for peer review to a LOT of people, so these problems can be patched almost immediately.
Re:I AM **SICK** OF STUPID BUFFER OVERFLOW HOLES!!
on
Solaris, AIX Login Hole
·
· Score: 3, Interesting
For instance: gdkxft, the program that provides AA fonts for GTK apps uses this technique too. This way, you don't have to patch and recompile the complete GTK lib. Instead you just overload existing functions, and viola, GTK has AA fonts, no recompile of GTK required.
It has its prositive uses and can be a timesaver if you need to test stuff out, but it's also a big security hazard if you're not careful...
In the case of telnet, then yes, they are shielded off, but in the case of ssh, this wasn't true. Of course, you can leverage with geuid and geteuid, but if both are equal it still happens./bin/login is being run as root here, because it needs to setuid() to the uid that you log in as. If the ssh daemon inadvertedly (sp?) still allows some of those dangerous envvars to be set, you are toast.
The suid bit matters, btw. If a non-root runs a suid program, then yes, some envvars are ignored/nullified. But if root runs it (of if it is being spawned by a root owned process), then that kite doesn not fly anymore and preloading just happens.
The daemon that runs as root must take care of these things, or just don't run that thing as root. It's btw perfectly possible to run sshd as a non-root, only then you can not bind the ssh port and I imagine you would have some problems running/bin/login (which is a bad idea anyway)
Another possibility/trampoline is the Global Offset Table (GOT), where the branch points to several library functions that the program uses are stored. This table is not read-only. Another possibility... And you don't even have to jump into libc (although you can):-)
The libraries can be stored in/tmp, your ftp incoming dir,/var/tmp, or even (if the user has a shell account) in the user's homedir.
All that is needed is a "setenv LD_PRELOAD/dir/where/lib/is/foolib.so" or something similar and the damage is done. The library is dynamically linked into the root-owned program that's running with root privs and the system is "0wned", like they say (I like to say compromised, but that's just me).
The fix is of course to not let ssh set these kind of envvars, which is what they fixed in SSH, which prevented exploitation on *BSD which didn't have the buffer overflow.
Yes this was a bug in SSH, not in login:-)
Re:Microwave (OT, sorry)
on
Lunar Lasers
·
· Score: 1
Uh, yeah, I've been here for quite some time. Check my user id:-)
(posting without +1)
Re:I AM **SICK** OF STUPID BUFFER OVERFLOW HOLES!!
on
Solaris, AIX Login Hole
·
· Score: 4, Interesting
Uhm, this is not just buffer overflow material. Let me explain why:
You can set $LD_LIBRARY_PATH and $LD_PRELOAD.
How is this relevant?
Say,/bin/login uses a few common library calls, like say strcpy(3), right? Or better yet, getpasswd(3), or crypt(3).
Now, If I create a library with replacement versions of those calls that say, spawn a root shell, and can preload it before/bin/login loads the calls from libc, I'm set. Hey, instant root shell, without writing even a single line of buffer overflow code. How you get your trojan lib on the victim box is an excersize for the reader:-)
So, what if they _did_ use strncpy(3)? Well, I create my replacement function for that as well, big deal. What calls you use doesn't really matter...
I agree in that buffer overflows are inexcusable, but holes like this are to be frowned upon as well...
That's not really the issue, it's about having the ability to send arbitrary information to a program (say, login, or every other prog that ends up being executed as root, be it suid or not). Still, being able to set env vars for the target program is _very_ dangerous ($LD_PRELOAD and $LD_LIBRARY_PATH come to mind)
A bug is a bug, and bugs need to be fixed. Period. You never now when this could end up in your face later. It's undesireable operation.
Re:Microwave
on
Lunar Lasers
·
· Score: 0, Flamebait
I think microwaving the earth from the moon is not going to work. There are too many disturbances and obstacles in outer space itself. There's background radiation, solar winds, x-rays, the earth magnetic field, and all that is going to seriously fsck up the transmission. I know it was Tesla's dream to transfer energy wirelessly, but this would probably put him in a hissy laughter fit... OTOH, imagine a Tesla coil that could send arcs of electricity to the earth... Yikes... (yeah, I know that's physicly impossible, but just _imagine_)
Nah, better would be if they used the generated electricity for the lunar infrastructure.
The laser thing bothers me a bit. Who says that one couldn't point such a thing towards the earth to blast stuff out of existance?
This is actually a feature of the SPARC processor. Actually, all RISC processors can do it. It involves being able to mark pages like the stack as non-executable (for storage only). This means that such a thing could also be done on PPC based CPU's. Of the OS must support it:-)
Of course making the stack executable is not a miracle cure. You can still execute arbitrary code through another trampoline (like jumping into libc, rewriting/patching functions through trojaned libraries ($LD_LIBRARY_PATH and $LD_PRELOAD for example) or other tricks).
Sorry if this is a little offtopic, but stack smashes aren't the only way to skin a cat.
Check the cvs-all@freebsd.org mailinglist for more info (the actual commit log is there). Oh. don't forget to mergemaster(1) after you build world, since this is also a configuration issue. Another fix was put in that prevents env variables to be passed on to login(1), which also helps in fixing this.
Of course, correct me when I'm wrong or off base on this here... I don't know about any Solaris patches or AIX fixes, since I don't generally use those platforms, but I bet they are either underway. See your local sunsolve outlet or your IBM patch repository.
Surely, the chance exist that wou won't get the position. What are you going to do if that's the case? Are you going to spend more time in advocating alternatives to Microsoft's products? Or are you going to mope in a corner?
> Theory that I learned in college indicates that there is a minimum number of bits that represent any information. Once compressed to that point, you can't go any further.
Exactly. This is also the point where a equasion to represent the data is going to end up bigger than the data its trying to send. But it depends on the algorythm used too. If the data may be sent out of order, one could try block-sorting and then compressing (like bzip2 does), but since this is UDP, out of order packets will be dropped or either not delt with (I think).
DISCLAIMER: I am not a protocol god, nor am I trying to be. Just spouting my views:-)
Slashdot Mirror
Someone seems to already have done it. And it was on slashdot as well.
Better yet, try Stella which emulates it for your platforms (dos/w32) _and_ all the others...
At OSX's core is a Mach microkernel with a 4.4BSD personality, and the libraries are based mostly from FreeBSD (from version 3.4 I believe, please correct me if I'm wrong here) and NEXTSTEP.
The only similarity between Mac OS X and NetBSD is the 4.4BSD'ishness of it all, but FreeBSD has that too. They did base it off of BSD because Next was based on 4.3BSD personality Mach microkernel.
ssh had a bug, it was only relevant if you used your system's login (which it doesn't by default, but you _can_ opt for that). Which can be handy if you use a non-standard login(1).
It wasn't just AIX/Solaris, it was also a ssh bug, which affected other platforms as well.
I'm not really much of an MS basher (I don't use their products, but that's just my choice), but bugs are bugs. Bugs happen. And you have to admit that /. (it's authors and much of the readership) is a bit biased when it comes to MS :-)
(oh, and it's quite late here now... bugger...)
Nifty... But it's still somewhat volatile and a lot can disturb it. I still doubt this can reliably be done in a "real world" environment
Call me sceptic :)
But just a thought, if attempts are made to make the signal "undetectable", isn't that falling into the 'security through obscurity' trap?
I find the assumption of "unbreakable crypto" a bit overzealous. Every crypto scheme can be cracked, only the time you have to invest in it seems to keep growing, and things seem to get more and more complex. The reason people feel save with high grade conventional crypto (thru PKI or be it symmetrical) is that it takes a *very* long time (as in hopefully centuries) to recover the message.
AFAIK, there is only one scheme that comes close to perfect, and that's the one time pad using a (dare I say) random "key" (say, a CD-R recorded with just white noise picked up from radio traffic or stellar background noise). If the "key" is handled in a secure manner, it's virtually unbeatable. Of course there is one VERY weak factor here, and that's the human factor, but still... Oh ironic is that the one time pad system is also the most simple one :-)
You forgot another tacktic: replay attacks.
You are also forgetting that there are other ways to skin that cat. Rewriting functions, returning into libc or rewriting GOT entries are another way to wreak havoc.
There's only one thing that really works: Code Reviews. Heck, programmers are human, they can slip up and make mistakes, even if they are the most careful coders in the world (they are still human). More eyeballs catch more bugs. And the next random person can spot a problem in five minutes that you are trying for days to prevent.
Bugs happen. Deal with it. The advantage that we open source people have is that our code is open for peer review to a LOT of people, so these problems can be patched almost immediately.
It has its prositive uses and can be a timesaver if you need to test stuff out, but it's also a big security hazard if you're not careful...
The suid bit matters, btw. If a non-root runs a suid program, then yes, some envvars are ignored/nullified. But if root runs it (of if it is being spawned by a root owned process), then that kite doesn not fly anymore and preloading just happens.
The daemon that runs as root must take care of these things, or just don't run that thing as root. It's btw perfectly possible to run sshd as a non-root, only then you can not bind the ssh port and I imagine you would have some problems running /bin/login (which is a bad idea anyway)
Another possibility/trampoline is the Global Offset Table (GOT), where the branch points to several library functions that the program uses are stored. This table is not read-only. Another possibility... And you don't even have to jump into libc (although you can) :-)
The libraries can be stored in /tmp, your ftp incoming dir, /var/tmp, or even (if the user has a shell account) in the user's homedir.
All that is needed is a "setenv LD_PRELOAD /dir/where/lib/is/foolib.so" or something similar and the damage is done. The library is dynamically linked into the root-owned program that's running with root privs and the system is "0wned", like they say (I like to say compromised, but that's just me).
The fix is of course to not let ssh set these kind of envvars, which is what they fixed in SSH, which prevented exploitation on *BSD which didn't have the buffer overflow.
Yes this was a bug in SSH, not in login :-)
(posting without +1)
You can set $LD_LIBRARY_PATH and $LD_PRELOAD.
How is this relevant?
Say, /bin/login uses a few common library calls, like say strcpy(3), right? Or better yet, getpasswd(3), or crypt(3).
Now, If I create a library with replacement versions of those calls that say, spawn a root shell, and can preload it before /bin/login loads the calls from libc, I'm set. Hey, instant root shell, without writing even a single line of buffer overflow code. How you get your trojan lib on the victim box is an excersize for the reader :-)
So, what if they _did_ use strncpy(3)? Well, I create my replacement function for that as well, big deal. What calls you use doesn't really matter...
I agree in that buffer overflows are inexcusable, but holes like this are to be frowned upon as well...
Heck, I learn something new every day :-)
A bug is a bug, and bugs need to be fixed. Period. You never now when this could end up in your face later. It's undesireable operation.
Nah, better would be if they used the generated electricity for the lunar infrastructure.
The laser thing bothers me a bit. Who says that one couldn't point such a thing towards the earth to blast stuff out of existance?
Of course making the stack executable is not a miracle cure. You can still execute arbitrary code through another trampoline (like jumping into libc, rewriting/patching functions through trojaned libraries ($LD_LIBRARY_PATH and $LD_PRELOAD for example) or other tricks).
Sorry if this is a little offtopic, but stack smashes aren't the only way to skin a cat.
Of course, correct me when I'm wrong or off base on this here... I don't know about any Solaris patches or AIX fixes, since I don't generally use those platforms, but I bet they are either underway. See your local sunsolve outlet or your IBM patch repository.
Surely, the chance exist that wou won't get the position. What are you going to do if that's the case? Are you going to spend more time in advocating alternatives to Microsoft's products? Or are you going to mope in a corner?
He's fighting a worthy cause. Buy some stuff from his website, he could sure use the support.
Exactly. This is also the point where a equasion to represent the data is going to end up bigger than the data its trying to send. But it depends on the algorythm used too. If the data may be sent out of order, one could try block-sorting and then compressing (like bzip2 does), but since this is UDP, out of order packets will be dropped or either not delt with (I think).
DISCLAIMER: I am not a protocol god, nor am I trying to be. Just spouting my views :-)