But crypto guys are paranoid like nobody else, and so they're naturally worried about this sort of thing. Mainly it's worrying to them because it's not a mathematical attack, which they're more used to. Modern crypto works based on theory and algorithims and such, and the idea that the algorithim being correct (for a given value of "correct") isn't enough to protect the security of the data is extremely worrying. A real world implementation of these algorithims now has to take some more real world facts into account, and this bothers them, of course.
They should be paranoid like nobody else. Crypto tends to be astonishingly brittle, see AirSnort and the recent IPSEC attacks. Like the timing attacks against SSH and the power analysis attacks against smart cards, this attack is difficult to carry out, but compromises everything (enough to finish the attack with brute force or partial-key methods) if it works. Then your server is hacked and it's game over.
Yep, and like the old maxim goes, there's no security if the attacker has physical access. Alot of this collegiate discussion of measuring voltages and doing fine-grained timing would require having physical access.
No. It requires having shell access. This is not the same as physical access, and a system should be secure against an attacker with shell access. Not that most are in fact secure, but they should be.
As for binary packages, yes, I know that it's possible to patch them, but ports updates faster when there's say a PHP vuln, so we still have to compile it. We usually update due to security vulns and so time is important.
And while I'm not a ports expert, neither I nor the HCS admins install system stuff via make, and so fixing broken dependencies in the package database is pretty irritating. Maybe there's a way to avoid this problem, but it's not in the Handbook.
I'm going to pitch in with GP on this one. I've been running FreeBSD 5.3 on a file/web/printserver for a while. I'll upgrade to 5.4 now, but this summer when I have more time, I'm going to switch to Linux (probably Debian or Ubuntu).
Why? Debian has a better package manager. I won't have to deal with portupgrade. I won't have to compile to get a package made this month; on a slow machine this is a big win. I won't have to wait 2 months for security fixes (cough MySQL). And FreeBSD has been stable, but not overwhelmingly so. The machine still crashes once a month or so, and half the time hangs during a reboot. Certain of the daemons die at random and thus have to be babysat by cronjobs or runscripts.
There are some things I'll miss though. For one, POSIX ACLs are built into FFS. For another, snapshots: FFS snapshots are much simpler and more efficient than LVM snapshots (any word on when someone's getting NetApp-style snapshots though?)
Simultaneously and independently, the Harvard Computer Society, of which I'm a member, is making a similar switch. They're switching to Debian for easier maintainability, and for grsec and/or systrace. HCS allows student groups to run scripts on their servers, which causes them to get hacked every once in a while (like when the phpbb exploits were 4ll t3h r4g3), and with grsec they should be better able to limit the damage. The main things they'll miss are pf (which they might get a hardware firewall to replace) and dump -L (much easier than LVM snapshots).
bash "/tmp/-i" would certainly behave as expected.
Actually, that doesn't work either. There is a race condition: an attacker may create a hard or soft link to a SUID script in/tmp/foo, exec it and then clobber it with another script. This is a race condition, and so after a thousand scripted runs the attacker might succeed in duping bash into exceuting an arbitrary script as root.
Exactly. Because it is the kernel that parses the commandline options.
OK. If you want to be anal, execv(scriptname, {scriptname, arg1, arg2, arg3, NULL}) is translated by the kernel to execv(interpreter, {interpreter, arg, scriptname, arg1, arg2, arg3, NULL}).
When have you ever seen a shell script without an invocation line?
Never.
If it was such a problem, why not make the shell disallow execution of scripts without an explicit invocation line?
bash -i is a perfectly reasonable command line. Bash doesn't know that it's being called to run a shell script, it just thinks that it's being called to log a user in. The kernel doesn't know that bash interprets -i this way...
which is then executed. If the script is setuid, then logically the interpreter should be setuid.
Suppose then that you have a bash script/usr/local/bin/foo which is setuid root. If I create a symlink to it at/tmp/-i and set my path to include ".", then I can invoke it from tmp as "-i". The kernel translates this to
/bin/bash -i
run setuid root, which is a root login shell. D'oh.
Linux fixes this (if you turn on setuid scripts) with the/dev/fd/n system, that is, it opens the script as file descriptor 3 (say), and runs
/bin/bash/dev/fd/3
Still, this is a hack, and setuid scripts are bad for other reasons (environment poisoning,...).
First, Apple didn't "steal" Darwin. It was based on BSD-licensed open source and they use it legally, and furthermore they maintain it as open source (which they are not required to do, but it costs them nothing so they do it anyway). The BSD community benefits from Apple's work in Darwin in several places, which doesn't hurt Apple because they don't compete with BSD.
Second, the best part of OS X is not the UNIX part. The kernel is stable and fast enough, and the BSD base system is OK, but really, Linux and Solaris are better for UNIXy things. What Apple wrote by themselves (and bought from NeXT, which was owned by their co-founder) was a GUI that is much better than any other GUI in any operating system, and a development environment to match it. This was never open source, and Apple did not "steal" it.
Finally, Mach and Darwin do not have fine-grained locking, and thus they suck on SMP. That's why Apple is adding fined-grain locking to Tiger, so their kernel synch isn't so monolithic. They're not stealing this either, they're writing it themselves, and it's possible that the BSD community will benefit from this, too (not sure how much it will only affect Mach stuff).
Apple has stolen plenty of designs (cough Watson cough), but this is not one of them.
Contraception is a vaccine for AIDS, it's just not as simple as an injection. Provided you don't get it though bad medical care that is, but that's unlikely provided the staff have had even very basic training.
Contraception is not a vaccine for AIDS, just as washing your hands frequently and not rubbing your eyes is not a vaccine for the flu. These are preventative measures.
A vaccine is a measure to boost immune system resistence to a specific pathogen by exposure to a weakened or killed form of it. Unlike contraception and the like, it affords a fairly high level of protection once and for all, or at least for say 10 years at which point you get a booster. Thus a hepatitis B vaccine that you got 5 years ago protects you (or has a good chance of protecting you) against hepatitis B if you get gang raped (a major problem especially in South Africa) or if you use a defective condom, or if you get bad medical care, or if you share needles, or if you get into a bloody brawl, or whatever. Contraception does not protect against these, and in fact condoms are not a tremendously effective measure against AIDS, even if they don't break.
A vaccine against AIDS would be an extremely effective measure against its advance, especially in countries where consensual sex is not the only common transmission mode. Education and distribution of contraceptives are important, but they are not a final solution.
However, you'd solve more of the abstract problems causing the poverty by giving out immunisations to common diseases rather than than serilization. Jeez, daily aids deaths are around 3,000 and they can't even give out enough contraception to them.
If anybody had a vaccine for AIDS, sub-Saharan Africa would be the first target. But nobody does. Of course, there are other diseases you could vaccinate for. But that doesn't solve the famine.
If people worked 90 hours a week at $7/hr in America... they'd still be more expensive than Chinese labor, possibly more than Indian programmers as well. You can live quite comfortably in India on $7/hr (think, $50-$75/hour in the US), and you don't even have to work long weeks. In fact, some CS students are moving from the US to India to become high-level designers and managers, and live like kings on much less than they would get in the States, because the cost of living is so low in India and there is a demand for English-speaking programmers and designers.
While I tend to understand the enthusiasm that each of these groups of students have towards their alma mater, I have to wonder if the Caltech kids are as smart as they think they are.
I'd much rather stay in warm CA during April than go to MA. Invite the MIT whiz kids down and haze them in the relative comfort of your own hometown. For chrissakes, what fun is it to freeze your ass off over there?
MIT has a weather machine. It's always warm and sunny on prefrosh weekend. This one was no exception.
Some people can't read without mouthing words to themselves. Perhaps surprisingly, in the past people have had the opposite reaction. St. Augustine was thought by some to be demonic or possessed because he could read without moving his lips.
I'm not so sure. Wireless security has been historically so bad, every bit of key randomness we can get is probably worth it.
Using a reasonably long passphrase which isn't a word, two words, a well-known sequence of numbers or a family member's birthday already puts you above the vast majority of people and essentially all attackers. They'd try an AirSnort attack long before true brute force, and if you're vulnerable to AirSnort, no amount of entropy will save you.
If you have a feasible attack on/dev/random, allowing you to guess even a single bit with substantially greater than 1/2 probability, which can be mounted interactively by non-root on a standard Linux machine -- or even on a Mac in which/dev/random doesn't pretend to have real entropy -- it's a major, publishable result. If this attack works after the fact to allow an attacker to break a wireless network set up a week ago using this method, it's nothing short of revolutionary. Someone holding such a major cryptographic breakthrough (a) probably doesn't exist, (b) would almost certainly be a major government if it did exist, (c) probably has enough money/power to get in more easily in other ways, and (d) will not waste such a break just to crack your stupid network (unless you are a Three Letter Agency or the like, in which case you're probably using fiber optics and have your building in a Faraday cage).
Even then, you're probably OK. Even at a bank, if your "152 bit" password really only has 80 bits of entropy, nobody gives a damn. Nobody can mount an 80-bit brute-force attack, even though it's offline, with possible exception of abovementioned Three Letter Agencies, and to mount an attack with less than brute force requires breaking RC4 much worse than it's already broken. Again, major break, and if a TLA has it, they're going to sit on it.
Anybody have experience with building and integrating a hardware random number generator?
Yes. But I can also tell you, a hardware RNG is overkill for these purposes. There is easily enough randomness available through/dev/random based on disk timings and such to make strong 152-bit keys. Alternatively, you can roll a bunch of dice.
Slashdot Mirror
For example I am setting up a nature webcam site which will be ipv6 only for exactly this reason.
You misspelled "mature".
You'll have to apt-get upgrade too...
But crypto guys are paranoid like nobody else, and so they're naturally worried about this sort of thing. Mainly it's worrying to them because it's not a mathematical attack, which they're more used to. Modern crypto works based on theory and algorithims and such, and the idea that the algorithim being correct (for a given value of "correct") isn't enough to protect the security of the data is extremely worrying. A real world implementation of these algorithims now has to take some more real world facts into account, and this bothers them, of course.
They should be paranoid like nobody else. Crypto tends to be astonishingly brittle, see AirSnort and the recent IPSEC attacks. Like the timing attacks against SSH and the power analysis attacks against smart cards, this attack is difficult to carry out, but compromises everything (enough to finish the attack with brute force or partial-key methods) if it works. Then your server is hacked and it's game over.
Yep, and like the old maxim goes, there's no security if the attacker has physical access. Alot of this collegiate discussion of measuring voltages and doing fine-grained timing would require having physical access.
No. It requires having shell access. This is not the same as physical access, and a system should be secure against an attacker with shell access. Not that most are in fact secure, but they should be.
Ah, didn't know about the systrace port, thanks.
As for binary packages, yes, I know that it's possible to patch them, but ports updates faster when there's say a PHP vuln, so we still have to compile it. We usually update due to security vulns and so time is important.
And while I'm not a ports expert, neither I nor the HCS admins install system stuff via make, and so fixing broken dependencies in the package database is pretty irritating. Maybe there's a way to avoid this problem, but it's not in the Handbook.
I'm going to pitch in with GP on this one. I've been running FreeBSD 5.3 on a file/web/printserver for a while. I'll upgrade to 5.4 now, but this summer when I have more time, I'm going to switch to Linux (probably Debian or Ubuntu).
Why? Debian has a better package manager. I won't have to deal with portupgrade. I won't have to compile to get a package made this month; on a slow machine this is a big win. I won't have to wait 2 months for security fixes (cough MySQL). And FreeBSD has been stable, but not overwhelmingly so. The machine still crashes once a month or so, and half the time hangs during a reboot. Certain of the daemons die at random and thus have to be babysat by cronjobs or runscripts.
There are some things I'll miss though. For one, POSIX ACLs are built into FFS. For another, snapshots: FFS snapshots are much simpler and more efficient than LVM snapshots (any word on when someone's getting NetApp-style snapshots though?)
Simultaneously and independently, the Harvard Computer Society, of which I'm a member, is making a similar switch. They're switching to Debian for easier maintainability, and for grsec and/or systrace. HCS allows student groups to run scripts on their servers, which causes them to get hacked every once in a while (like when the phpbb exploits were 4ll t3h r4g3), and with grsec they should be better able to limit the damage. The main things they'll miss are pf (which they might get a hardware firewall to replace) and dump -L (much easier than LVM snapshots).
It was obviously a typo. No processor these days run on 7V. They generally run on like 0.9v-1.4v
Once you show me a notebook that takes 1.5" drives, I'll believe you...
Doesn't NetBSD support dump -L the way FreeBSD does? This strikes me as a much more powerful and general solution than this custom tool...
bash "/tmp/-i" would certainly behave as expected.
/tmp/foo, exec it and then clobber it with another script. This is a race condition, and so after a thousand scripted runs the attacker might succeed in duping bash into exceuting an arbitrary script as root.
Actually, that doesn't work either. There is a race condition: an attacker may create a hard or soft link to a SUID script in
Exactly. Because it is the kernel that parses the commandline options.
OK. If you want to be anal,
execv(scriptname, {scriptname, arg1, arg2, arg3, NULL}) is translated by the kernel to
execv(interpreter, {interpreter, arg, scriptname, arg1, arg2, arg3, NULL}).
Happy?
When have you ever seen a shell script without an invocation line?
Never.
If it was such a problem, why not make the shell disallow execution of scripts without an explicit invocation line?
bash -i is a perfectly reasonable command line. Bash doesn't know that it's being called to run a shell script, it just thinks that it's being called to log a user in. The kernel doesn't know that bash interprets -i this way...
The problem with suid scripts is the mechanism for implementing scripts. Essentially, a script is an executable beginning with (arg is often left blank). When you run it, is translated by the kernel to which is then executed. If the script is setuid, then logically the interpreter should be setuid.
Suppose then that you have a bash script
Linux fixes this (if you turn on setuid scripts) with the
> My database server has a firewall in place to protect its copy of MySQL. Only my http server can connect on that port...
Sounds like a job for UNIX domain sockets and proper file system permissions.
Only if his webserver and database server are running on the same machine.
Don't forget:
4) This research is done by a woman.
Thank you, Larry Summers.
I know, don't feed the trolls...
First, Apple didn't "steal" Darwin. It was based on BSD-licensed open source and they use it legally, and furthermore they maintain it as open source (which they are not required to do, but it costs them nothing so they do it anyway). The BSD community benefits from Apple's work in Darwin in several places, which doesn't hurt Apple because they don't compete with BSD.
Second, the best part of OS X is not the UNIX part. The kernel is stable and fast enough, and the BSD base system is OK, but really, Linux and Solaris are better for UNIXy things. What Apple wrote by themselves (and bought from NeXT, which was owned by their co-founder) was a GUI that is much better than any other GUI in any operating system, and a development environment to match it. This was never open source, and Apple did not "steal" it.
Finally, Mach and Darwin do not have fine-grained locking, and thus they suck on SMP. That's why Apple is adding fined-grain locking to Tiger, so their kernel synch isn't so monolithic. They're not stealing this either, they're writing it themselves, and it's possible that the BSD community will benefit from this, too (not sure how much it will only affect Mach stuff).
Apple has stolen plenty of designs (cough Watson cough), but this is not one of them.
Contraception is a vaccine for AIDS, it's just not as simple as an injection. Provided you don't get it though bad medical care that is, but that's unlikely provided the staff have had even very basic training.
Contraception is not a vaccine for AIDS, just as washing your hands frequently and not rubbing your eyes is not a vaccine for the flu. These are preventative measures.
A vaccine is a measure to boost immune system resistence to a specific pathogen by exposure to a weakened or killed form of it. Unlike contraception and the like, it affords a fairly high level of protection once and for all, or at least for say 10 years at which point you get a booster. Thus a hepatitis B vaccine that you got 5 years ago protects you (or has a good chance of protecting you) against hepatitis B if you get gang raped (a major problem especially in South Africa) or if you use a defective condom, or if you get bad medical care, or if you share needles, or if you get into a bloody brawl, or whatever. Contraception does not protect against these, and in fact condoms are not a tremendously effective measure against AIDS, even if they don't break.
A vaccine against AIDS would be an extremely effective measure against its advance, especially in countries where consensual sex is not the only common transmission mode. Education and distribution of contraceptives are important, but they are not a final solution.
However, you'd solve more of the abstract problems causing the poverty by giving out immunisations to common diseases rather than than serilization. Jeez, daily aids deaths are around 3,000 and they can't even give out enough contraception to them.
If anybody had a vaccine for AIDS, sub-Saharan Africa would be the first target. But nobody does. Of course, there are other diseases you could vaccinate for. But that doesn't solve the famine.
If people worked 90 hours a week at $7/hr in America... they'd still be more expensive than Chinese labor, possibly more than Indian programmers as well. You can live quite comfortably in India on $7/hr (think, $50-$75/hour in the US), and you don't even have to work long weeks. In fact, some CS students are moving from the US to India to become high-level designers and managers, and live like kings on much less than they would get in the States, because the cost of living is so low in India and there is a demand for English-speaking programmers and designers.
While I tend to understand the enthusiasm that each of these groups of students have towards their alma mater, I have to wonder if the Caltech kids are as smart as they think they are.
I'd much rather stay in warm CA during April than go to MA. Invite the MIT whiz kids down and haze them in the relative comfort of your own hometown. For chrissakes, what fun is it to freeze your ass off over there?
MIT has a weather machine. It's always warm and sunny on prefrosh weekend. This one was no exception.
>those that can't read without moving their lips
huh?
Some people can't read without mouthing words to themselves. Perhaps surprisingly, in the past people have had the opposite reaction. St. Augustine was thought by some to be demonic or possessed because he could read without moving his lips.
He's OSX fnord Apple on to us... we'll have to fnord fall back to a more secure channel OSX.
I'm not so sure. Wireless security has been historically so bad, every bit of key randomness we can get is probably worth it.
/dev/random, allowing you to guess even a single bit with substantially greater than 1/2 probability, which can be mounted interactively by non-root on a standard Linux machine -- or even on a Mac in which /dev/random doesn't pretend to have real entropy -- it's a major, publishable result. If this attack works after the fact to allow an attacker to break a wireless network set up a week ago using this method, it's nothing short of revolutionary. Someone holding such a major cryptographic breakthrough (a) probably doesn't exist, (b) would almost certainly be a major government if it did exist, (c) probably has enough money/power to get in more easily in other ways, and (d) will not waste such a break just to crack your stupid network (unless you are a Three Letter Agency or the like, in which case you're probably using fiber optics and have your building in a Faraday cage).
Using a reasonably long passphrase which isn't a word, two words, a well-known sequence of numbers or a family member's birthday already puts you above the vast majority of people and essentially all attackers. They'd try an AirSnort attack long before true brute force, and if you're vulnerable to AirSnort, no amount of entropy will save you.
If you have a feasible attack on
Even then, you're probably OK. Even at a bank, if your "152 bit" password really only has 80 bits of entropy, nobody gives a damn. Nobody can mount an 80-bit brute-force attack, even though it's offline, with possible exception of abovementioned Three Letter Agencies, and to mount an attack with less than brute force requires breaking RC4 much worse than it's already broken. Again, major break, and if a TLA has it, they're going to sit on it.
Anybody have experience with building and integrating a hardware random number generator?
/dev/random based on disk timings and such to make strong 152-bit keys. Alternatively, you can roll a bunch of dice.
Yes. But I can also tell you, a hardware RNG is overkill for these purposes. There is easily enough randomness available through
If you really, really want a hardware RNG, go for a Soekris card or a C3 processor, or make your own RNG (integrating that would be tougher, though).
You see, the advantage of suicide software is that the users never survive to complain about the bugs.
Depends on how serious the bugs are.