Its actually pretty much impossible to get Linus to do something that he doesn't want to. Linus has control over the Linux source and has a singular vision. And largely Linus is a software developer who cares about engineering the core of the O/S to be fast and efficient and teaching himself O/S design as he goes along. Linux really is Linus' summer project run out of control.
It is not, however, an enterprise class O/S. Want a kernel debugger? Well, there's a patch that might be up to date. Want to profile the kernel to debug the slowdowns in your 8-way profusion database server? Good luck if you don't have a kernel developer on your staff (and those are reasonably difficult for your average website to find and employ).
And Linus will never allow this kind of "cruft" into his kernel. His opinion is that there should be a high bar of standard for people who want to hack on his kernel. He's not going to make it any easier for very advanced system admins who want a kernel debugger, crash dump analysis and better ways out of the box to profile the kernel. (Read the linux-kernel mailing list if you'd like to -- Linus has said as much).
None of this goes over well with businesses, at least not for the Enterprise server market. It may be more than adequate for the desktop though (who cares about profiling a kernel sitting on a desktop?). So, if you'd really like to face reality, Linux is the Win98 of Unix OSen. And Linus is trying to keep his kernel that way. The only alternative is to fork the damn thing and its way overdue for Linux distros and companies like SGI and IBM that have some Linux investment to go ahead and do so.
Are there any plans to make OpenBSD run on SMP
systems using a big kernel lock for mutual exclusion? This would seem to be a reasonably simple and safe approach to SMP, if not the best performing one. The usefulness might seem limited but one possible application is an IDS box that sniffed network traffic in one process while handling analysis in other processes running on the other CPUs in user space.
And focusing on OpenBSDs strengths, a second step to remove the BKL for the networking code could
result in useful SMP for firewalling, VPN and IDS applications under SMP. Any plans or thoughts on minimal SMP support like this for OpenBSD?
Saying the universe started in a central place and then expanded from there is misleading if not totally inaccurate. According to the big bang
theory the universe was a singular point in the
beginning. This means that not only was all the
mass compressed into a single zero dimensional dot
but that space-time itself was a singular point.
In order to understand this, you have to understand that space-time itself can bend, expand and contract, and that this is the most important feature of the expanding universe -- not the matter that sits inside the universe. The big bang was not an explosion which happened at a single point and then the material radiated outwards in a shell like a conventional explosion taking place. The big bang actually happened at every point in space. The big bang happened where you are sitting now.
Galaxies are actually not moving very fast, even though we may be seeing the distance between us and them get greater and we may see a large redshift from them as they get farther away from us. What is changing is space-time in between us and them which is expanding and placing them farther away from us. It is not the galaxies which are moving, it is space time that is warping (and there is no spoon).
Another aspect of this is that space-time can be much, much larger than the 10-20 billion light years which would be possible if it were a conventional explosion. If the universe exploded from a point on a flat background space-time (the wrong picture), then material would have been limited to the speed of light and the radius of the universe would be fixed to be less than a number light years equal to the age of the universe. However, if the big bang happened everywhere there is no limit to the size of the universe. It could be 10,20,100,1000, etc billion light years or even infinite in size.
Some of this may be a bit hard to swallow -- I find the part about the universe coming from a point-size singularity particularly hard to swallow -- but other aspects of the theory are well tested. We know that the theory of the big bang is correct back to the time when the universe was expanding fairly rapidly and was around 3000 degrees kelvin. We can actually see the light from that time as the cosmic microwave background radation (CMBR). Observations of the CMBR along with stellar nucleosynthesis and other observations have established the post-3000K big bang theory very well.
I don't suppose you remember the "Imminent death of the net predicted, film at 11" threads back on news.* (and the rest of Usenet) circa 1991-1993 do you? Applying the same logic at that time, I could have argued that as I was user number N of the internet (where N was probably in 100,000s back then), it was likelier that there would only be a few 100,000 users of the Internet ever, and that in fact the internet was most likely due to croak by 1995 or so. In fact, given the fact that we're up in the tens of millions of users now, I can make a much stronger argument for the imminent death of the internet now than i could back in 1992.
Unfortunately, to have a reversible computer you need lots of state. So, it may not take any energy to operate, but you wind up needing more bits than there are protons in the universe. The thermodynamic argument just needs to be modified.
And quantum computers only buy you sqrt(N) speed increase in brute force cracking, so if 128-bits is secure against a classical computer, then 256-bits will be secure against the equivalent attack by a quantum computer.
The example isn't wrong, but perhaps a little confusing. I'm not exploiting the sprintf(), I'm exploiting the call to syslog() which also uses format strings.
And really the best way to avoid these bugs is to avoid using anything other than fixed format strings. One way the bug occurs is (building on my previous example):
mysyslog(char *foo) {
syslog(LOG_DEBUG, foo);
}
(Obviously this is an example and mysyslog() in the real world probably does a few other things that the programmer always wanted to do when syslogging). Then the programer calls:
mysyslog("foobar");
All over the place and is fine until they start getting tricky and constructing error messages like:
(Sorry for the duplicate, hit the fscking submit button when I meant to hit preview...)
The problem comes about when you accept user input and then send it to vsprintf(), setproctitle(), syslog() or similar C programs that accept format strings. The seemingly innocuous code usually looks something like this:
Now an attacker can shove a string into the hostile_user_input variable like "%s%s%s%s" which will then be passed to syslog which whill execute:
syslog(LOG_DEBUG, "some message: %s%s%s%s");
Notice that this isn't a "valid" format string. It tends to do odd things since it goes looking for function arguments that aren't actually there. Clever construction of the hostile format string will lead to an exploit. This was used in the wu-ftpd remote setproctitle() exploit and the recent linux rpc.statd syslog() remote exploit.
All OSen which have code compiled from C and which use the vsprintf(), syslog(), setproctitle(), etc functions are potentially vulnerable to these attacks. There are undoubtably these kinds of vulnerabilities lurking within W2K somewhere...
The problem comes about when you accept user input and then send it to vsprintf(), setproctitle(), syslog() or similar C programs that accept format strings. The seemingly innocuous code usually looks something like this:
char buffer[1024];
[...]
sprintf(buffer, "some message: %s", hostile_user_input);
syslog(LOG_DEBUG, buffer);
Now an attacker can shove a string into the hostile_user_input variable like "%s%s%s%s" which will then be passed to syslog which whill execute:
syslog(LOG_DEBUG, "some message: %s%s%s%s");
Clever construction of the hostile format string will lead to an exploit.
The presentation of the Higgs working group is Here. If I understand correctly they're claiming to see three sigma results at the aleph detector, which is certainly good enough to announce a possible discovery, particularly when confirmed by similar results from the other 3 detectors at LEP. The people who are claiming that this is only a political annoucement to try to extend the life of LEP don't know what they're talking about.
When I released shellcode for Digital Unix, I did so after having given Compaq months to fix their problems. After releasing it I was contacted by people who had developed the same exploits over a year previously and disclosed them to Digital/Compaq and they had done nothing. By releasing actual exploits to the wilds they actually got their shit together and fixed the bugs and started shipping their O/S with root having a non-exec stack by default. That's a net security benefit (non-exec stacks on alpha architecture are very tough to crack) caused by public disclosure of an exploit.
Great. So the Windoze user at home gets hacked and back orificed, and now the hackers have a direct connection into your trusted network.
If you're going to do this you need a client on the windows side which will let you enforce security policy on the clients which connect to the VPN gateway. There are no Open Source products which will do this for you. You will probably need Checkpoint's FW-1.
The alternative is to simply not allow machines at people's homes to connect to your VPN gateway. Only do VPN when its gateway-to-gateway between satellite offices. No road warriors, no home users, and no need to support PPTP.
If you are looking to impliment PoPToP I urge you to take a very very long look at the security of the clients which are going to be connecting to the PoPToP server. You are probably going to make your network less secure, not more secure, by supporting PPTP on your VPN gateway.
[ Okay, not exactly a confession, but it was the snappiest title I could think of ]
Back around 1991 or 1992 I setup what I believe is was the first drug information site on the internet using the University of Washington's publically accessable FTP server. The information in that site was incorporated into hyperreal and from there into lycaeum and erowid. I've authored texts on how to Synthesize MDMA and Synthesize LSD.
I would just like to know how we're supposed to have discussions about heavy metal contaminants in methamphetamine synthesis or chromates in methcathinone if we can't discuss how those drugs are actually manufactured? What is different about me reading about how to synthesize drugs on the net and going down to the medical and chemistry libraries at my local university and reading about them there? The latter information is necessary for professionals and scholars to be able to intelligently discuss issues surrounding the synthesis of illegal drugs. Why are people on the net being singled out for exclusion and not being allowed to access this information?
If this law passes I plan on putting up a site which contains exactly the same kinds of information that you can get from the journal of forensic science or journal of medicinal chemsitry but violates the law by including information on the synthesis of illegal drugs (just like those journals do).
This proposed law is blatantly unconstitutional and Diane Feinstein can kiss my ass.
Instead of sticking libsafe in/etc/ld.so.preload and risking a bug taking out applications that you don't really want libsafe'd (I'm ignoring for the moment entirely valid arguments that all code is potentially privaleged and should be protected) there is another way to protect SUIDs. If you put libsafe in/lib with appropriate symlinks, and recompile suid programs with -lsafe then the programs will be dynamically linked against libsafe and will be protected without having to libsafe your entire distribution.
Ex:
% ls -1F/lib/libsafe* /lib/libsafe.so@ /lib/libsafe.so.1@ /lib/libsafe.so.1.3*
% cat foo.c
#include
The first and obvious problems is that it only protects these library functions. It will not prevent the case of someone doing a roll-your-own strcpy() and overflowing a buffer that way.
Another problem is that it caps the length of
the buffer at the size of the stack frame. While I can appreciate why this is the only realistic way to figure out the buffer size without incuring penalties, it doesn't prevent attacks against other data (e.g. pointers, function pointers) in the same stack frame as the buffer.
It also doesn't prevent heap overflows.
Also, I've got some concerns about the way that they've re-implimented some of these function calls. I haven't seen any reports yet from people that have thoroughly audited their functions for compatibility against the libc functions. Since they've reimplimented them differently, they may not have exactly the same side effects.
Still, since non-exec stacks on x86 are worthless and StackGuard has not yet been ported to egcs/RH6.x I'm seriously considering deploying this library to crucial systems.
Slashdot Mirror
It is not, however, an enterprise class O/S. Want a kernel debugger? Well, there's a patch that might be up to date. Want to profile the kernel to debug the slowdowns in your 8-way profusion database server? Good luck if you don't have a kernel developer on your staff (and those are reasonably difficult for your average website to find and employ).
And Linus will never allow this kind of "cruft" into his kernel. His opinion is that there should be a high bar of standard for people who want to hack on his kernel. He's not going to make it any easier for very advanced system admins who want a kernel debugger, crash dump analysis and better ways out of the box to profile the kernel. (Read the linux-kernel mailing list if you'd like to -- Linus has said as much).
None of this goes over well with businesses, at least not for the Enterprise server market. It may be more than adequate for the desktop though (who cares about profiling a kernel sitting on a desktop?). So, if you'd really like to face reality, Linux is the Win98 of Unix OSen. And Linus is trying to keep his kernel that way. The only alternative is to fork the damn thing and its way overdue for Linux distros and companies like SGI and IBM that have some Linux investment to go ahead and do so.
And focusing on OpenBSDs strengths, a second step to remove the BKL for the networking code could result in useful SMP for firewalling, VPN and IDS applications under SMP. Any plans or thoughts on minimal SMP support like this for OpenBSD?
In order to understand this, you have to understand that space-time itself can bend, expand and contract, and that this is the most important feature of the expanding universe -- not the matter that sits inside the universe. The big bang was not an explosion which happened at a single point and then the material radiated outwards in a shell like a conventional explosion taking place. The big bang actually happened at every point in space. The big bang happened where you are sitting now.
Galaxies are actually not moving very fast, even though we may be seeing the distance between us and them get greater and we may see a large redshift from them as they get farther away from us. What is changing is space-time in between us and them which is expanding and placing them farther away from us. It is not the galaxies which are moving, it is space time that is warping (and there is no spoon).
Another aspect of this is that space-time can be much, much larger than the 10-20 billion light years which would be possible if it were a conventional explosion. If the universe exploded from a point on a flat background space-time (the wrong picture), then material would have been limited to the speed of light and the radius of the universe would be fixed to be less than a number light years equal to the age of the universe. However, if the big bang happened everywhere there is no limit to the size of the universe. It could be 10,20,100,1000, etc billion light years or even infinite in size.
Some of this may be a bit hard to swallow -- I find the part about the universe coming from a point-size singularity particularly hard to swallow -- but other aspects of the theory are well tested. We know that the theory of the big bang is correct back to the time when the universe was expanding fairly rapidly and was around 3000 degrees kelvin. We can actually see the light from that time as the cosmic microwave background radation (CMBR). Observations of the CMBR along with stellar nucleosynthesis and other observations have established the post-3000K big bang theory very well.
Hope that helps a bit...
I don't suppose you remember the "Imminent death of the net predicted, film at 11" threads back on news.* (and the rest of Usenet) circa 1991-1993 do you? Applying the same logic at that time, I could have argued that as I was user number N of the internet (where N was probably in 100,000s back then), it was likelier that there would only be a few 100,000 users of the Internet ever, and that in fact the internet was most likely due to croak by 1995 or so. In fact, given the fact that we're up in the tens of millions of users now, I can make a much stronger argument for the imminent death of the internet now than i could back in 1992.
Unfortunately, to have a reversible computer you need lots of state. So, it may not take any energy to operate, but you wind up needing more bits than there are protons in the universe. The thermodynamic argument just needs to be modified. And quantum computers only buy you sqrt(N) speed increase in brute force cracking, so if 128-bits is secure against a classical computer, then 256-bits will be secure against the equivalent attack by a quantum computer.
And really the best way to avoid these bugs is to avoid using anything other than fixed format strings. One way the bug occurs is (building on my previous example):
mysyslog(char *foo) {
syslog(LOG_DEBUG, foo);
}
(Obviously this is an example and mysyslog() in the real world probably does a few other things that the programmer always wanted to do when syslogging). Then the programer calls:
mysyslog("foobar");
All over the place and is fine until they start getting tricky and constructing error messages like:
sprintf(buffer, "error message: %s", foo);
mysyslog(buffer);
Which looks perfect reasonable, but of course is exploitable if foo is user-supplied. The fix is that mysyslog() needs to be rewritten to look like:
mysyslog(char *foo) {
syslog(LOG_DEBUG, "%s", foo);
}
Hole closed.
The problem comes about when you accept user input and then send it to vsprintf(), setproctitle(), syslog() or similar C programs that accept format strings. The seemingly innocuous code usually looks something like this:
char buffer[1024];
[...]
sprintf(buffer, "some message: %s", hostile_user_input);
syslog(LOG_DEBUG, buffer);
Now an attacker can shove a string into the hostile_user_input variable like "%s%s%s%s" which will then be passed to syslog which whill execute:
syslog(LOG_DEBUG, "some message: %s%s%s%s");
Notice that this isn't a "valid" format string. It tends to do odd things since it goes looking for function arguments that aren't actually there. Clever construction of the hostile format string will lead to an exploit. This was used in the wu-ftpd remote setproctitle() exploit and the recent linux rpc.statd syslog() remote exploit.
All OSen which have code compiled from C and which use the vsprintf(), syslog(), setproctitle(), etc functions are potentially vulnerable to these attacks. There are undoubtably these kinds of vulnerabilities lurking within W2K somewhere...
char buffer[1024];
[...]
sprintf(buffer, "some message: %s", hostile_user_input);
syslog(LOG_DEBUG, buffer);
Now an attacker can shove a string into the hostile_user_input variable like "%s%s%s%s" which will then be passed to syslog which whill execute:
syslog(LOG_DEBUG, "some message: %s%s%s%s"); Clever construction of the hostile format string will lead to an exploit.
The presentation of the Higgs working group is Here. If I understand correctly they're claiming to see three sigma results at the aleph detector, which is certainly good enough to announce a possible discovery, particularly when confirmed by similar results from the other 3 detectors at LEP. The people who are claiming that this is only a political annoucement to try to extend the life of LEP don't know what they're talking about.
When I released shellcode for Digital Unix, I did so after having given Compaq months to fix their problems. After releasing it I was contacted by people who had developed the same exploits over a year previously and disclosed them to Digital/Compaq and they had done nothing. By releasing actual exploits to the wilds they actually got their shit together and fixed the bugs and started shipping their O/S with root having a non-exec stack by default. That's a net security benefit (non-exec stacks on alpha architecture are very tough to crack) caused by public disclosure of an exploit.
If you're going to do this you need a client on the windows side which will let you enforce security policy on the clients which connect to the VPN gateway. There are no Open Source products which will do this for you. You will probably need Checkpoint's FW-1.
The alternative is to simply not allow machines at people's homes to connect to your VPN gateway. Only do VPN when its gateway-to-gateway between satellite offices. No road warriors, no home users, and no need to support PPTP.
If you are looking to impliment PoPToP I urge you to take a very very long look at the security of the clients which are going to be connecting to the PoPToP server. You are probably going to make your network less secure, not more secure, by supporting PPTP on your VPN gateway.
Back around 1991 or 1992 I setup what I believe is was the first drug information site on the internet using the University of Washington's publically accessable FTP server. The information in that site was incorporated into hyperreal and from there into lycaeum and erowid. I've authored texts on how to Synthesize MDMA and Synthesize LSD.
I would just like to know how we're supposed to have discussions about heavy metal contaminants in methamphetamine synthesis or chromates in methcathinone if we can't discuss how those drugs are actually manufactured? What is different about me reading about how to synthesize drugs on the net and going down to the medical and chemistry libraries at my local university and reading about them there? The latter information is necessary for professionals and scholars to be able to intelligently discuss issues surrounding the synthesis of illegal drugs. Why are people on the net being singled out for exclusion and not being allowed to access this information?
If this law passes I plan on putting up a site which contains exactly the same kinds of information that you can get from the journal of forensic science or journal of medicinal chemsitry but violates the law by including information on the synthesis of illegal drugs (just like those journals do).
This proposed law is blatantly unconstitutional and Diane Feinstein can kiss my ass.
Ex:
% ls -1F /lib/libsafe*
/lib/libsafe.so@
/lib/libsafe.so.1@
/lib/libsafe.so.1.3*
/lib/libsafe.so.1 (0x4001c000) /lib/libc.so.6 (0x40021000) /lib/libdl.so.2 (0x40116000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) ./foo `perl -e '{ print "A" x 1040 }'` /home/lamont/security/non-exec/foo.
% cat foo.c
#include
void foo(char *string) {
char buffer[1024];
strcpy(buffer, string);
}
int main(int argc, char *argv[]) {
foo(argv[1]);
}
% gcc -o foo foo.c -lsafe
% ldd foo
libsafe.so.1 =>
libc.so.6 =>
libdl.so.2 =>
%
Detected an attempt to write across stack boundary.
Terminating
You can make that executable suid root and it works the same.
Another problem is that it caps the length of the buffer at the size of the stack frame. While I can appreciate why this is the only realistic way to figure out the buffer size without incuring penalties, it doesn't prevent attacks against other data (e.g. pointers, function pointers) in the same stack frame as the buffer.
It also doesn't prevent heap overflows.
Also, I've got some concerns about the way that they've re-implimented some of these function calls. I haven't seen any reports yet from people that have thoroughly audited their functions for compatibility against the libc functions. Since they've reimplimented them differently, they may not have exactly the same side effects.
Still, since non-exec stacks on x86 are worthless and StackGuard has not yet been ported to egcs/RH6.x I'm seriously considering deploying this library to crucial systems.