Is it OpenBSD that is keeping you safe, or is it that you have the wisdom to avoid running sketchy programs on your computer combined with the fact that there isn't much malware for OpenBSD out there waiting for you to run?
If we entered the twilight zone and imagine that OpenBSD was the dominent player in the consumer OS market we would still have tons of zombies doing bad things. Sure, thanks to ProPolice, W^X, and Guard Pages bugs in MSN and Outlook Express for OpenBSD would be less exploitable than is the case in Windows right now. None of these things help when users run programs sent by their worm infected friends. Nothing in OpenBSD prevents programs from debugging other processes running as the same user and modifying them on the fly either.
And even in an alternate universe it's questionable if making the legacy-binary-breaking changes required by these features would have allowed it to remain the dominant OS.
OpenBSD is really cool. The latest release brings some great new features.
It's now possible to have a *fully* redundant firewall/vpn box. (support for keeping filter, nat, queue, ipsec states sync'd on all nodes, support for takeover of failed device, support for interface trunking for layer2 redundancy...) It works very well and it's a snap to setup since everything is in the default install.
Mark Uemura is giving a talk about this at PacSec this november in Tokyo.
Here are slides from an older one he did.
> When it comes to reporting flaws you are no
> longer dealing with computers but with people
> and if you piss them off to much they will be
> less then helpful.
If you ever find yourself being accused of not practicing responsible disclosure you can take comfort in the fact that you cannot be responsible for everyone's needs. The term "responsible disclosure" doesn't include the part about who you are supposed to be responsible for, that's up to you to decide.
In my humble opinion, the correct way to disclose a bug is however you feel like doing it. You found it. You don't owe anybody for that. Maybe you believe that the fastest route to a more secure and reliable world of software is if people who choose to use certain software are punished as often as possible so that they switch to software written by a more responsible party. Who knows? Maybe it could work. It is definitely not immoral or irresponsible to believe this since we don't know what does work. If there was one obvious true way to make a hole public (or not) that had no ill effects then everyone would be doing that already. duh.
If a researcher, with no prior contact with the vendor posts a vulnerability out of the blue then the people who work at the vendor are going to be pissed. They are going to call the researcher "irresponsible", but that's only because they have to maintain a certain amount of class. They really just think he's an asshole because he is going out of his way to make things harder than they need to be for the developers and the customers who use the software.
I do not think many researchers are acting this way.
On the flipside, when researchers contact a vendor in good faith and that vendor treats them badly then it is unreasonable for the vendor to expect any more good faith efforts from that researcher.
As you so aptly pointed out, having tact is key. If the researcher does a vendor the courtesy of giving advanced notice, and he is open and honest about his motovations and expectations, whatever they are, then I say he is responsible.
examples:
A researcher who found bug by fuzzing, currently has _no evidence_ that it is being exploited giving a heads up to the vendor:
"hi I just found this remotely exploitable heap overflow in WizBang. All versions starting from 2.1 are vulnerable. You can reproduce this bug by blah blah blah. I plan to discuss this during my presentation at PacSec, a security
conference that focuses on new research which is being held in Japan on November 15th. You should make sure you have patches ready before then. let me know if you need any more info."
It doesn't matter at all if the vendor really can't fix the problem before then, because it is a major design flaw requiring huge rewrite that will screw over the release schedule for the next 6 months. The vendor may say this and try to stall, then call the researcher "irresponsible" when he follows through and goes public, but it's nothing more than selfish whining. When someone who you don't even know offers you something highly valueable for free you are in no position to start making demands. It is utterly mind boggling how certain companies try to justify behaving this way.
In this example the researcher is being responsible for himself and his career by making it known to vendors who believe they are ultimately responsible for finding their own bugs that he would be worthy of hiring. Or he's making it know that his company has smart people who can find and exploit bugs, not a bunch of monkeys who charge money for running nessus. Either one thing that sure ISN'T his concern is making sure the vendor can patch in time. No amount of vendor temper tantrums can force him to take on that responsibility. How is it even possible to be responsible for the actions of a bunch of programmers who don't even work for you???
Here's another example of responsible disclosure that's sure to draw flames.
I'm tired of these commercials I see on TV that advertise some DVD. they all say, in that voice, you know the one:
"OWN IT TODAY ON DVD"
It should be illegal for them to say that. It's false advertising. If I could actually "own it on dvd" then I could make as many copies as I please. say what you will about piracy of music and movies, but before you give these fuckers the moral highground how about they start telling the TRUTH and say,
"LICENSE IT TODAY ON DVD"
yeah, doesn't quite have the same ring to it, huh?
SPF^H^H^HSenderID. The whole attach senders IP to their domain with a new DNS record idea may or may not be good, but in either case microsoft patented methods already existing in SPF, offered a license incompatable with free software, then insinuated they would take action against implementers. They used a trivial patent to derail the hard work of many people.
maybe, just maybe, in the entire world, there are a handful software ideas each year that are worthy of a patent.
I think RSA for example was a worthy invention. 20 years is also way too long for software. 5 years is more reasonable.
I really think they are lying about not keeping IP addresses in logs at all. If I were the UK police I would have been running for a search warrent as soon as they said "we don't have that data". like FAST. Cause they probably deleted it which means the sooner I can get my hands on that drive the less work it will be to get my clues off it.
The net is so spammy these days. How when some jerk posts a tons of crap to their site how do they know his IP address to ban him? Leave tcpdump outputting to a console and have a real good memory? I don't think so. Apperently they were banning by IP. (go ahead, correct me if that's not true of that particular IM site) Most likely they stored the usual access_log but they deleted it frequently.. or at least they thought they did. It is utterly impossible to delete data from magnetic media. If you are trying to hide something from the police it better not *ever* have been written to disk in plaintext.
They should have bought a fresh hard drive and copied the files over from the old one (cp -a or tar, but not dd!) and then taken a hammer to the original, and thrown it in a ramdom dumpster. If it was ever found they could claim "oh that drive was already dead" and because it won't spin correctly any more cost of forensics on it is through the roof. Then they could have said "sure detective, I'd be happy to help. Why don't you bring a hard drive with you at least X gigs and we can make you an image"
At least by storing it in a RAM disk like the parent suggests the data will get overwritten many times over short periods of time which will surely make forensics more difficult.
Swap is just as easy to encrypt. For swap you always just create a crypto loop device with a random key at startup, create a new swap space on it and enable. OpenBSD can do this internally. It's trivial with all other free unix systems.
There is no point in encrypting the system or the content since that is all public anyway. At issue here are the logs - and yes, there are logs otherwise how would they go about banning based on IP address as stated in the Wikipedia article about them?
The correct solution here is to have the system create a random key upon startup and create a fresh filesystem where the logs will be stored. If the system is seized and powered off for cold anaylsis then the key will be lost. Not even the system admins would know it - and if they don't know it they can't be held liable for it even if the UK does consider it a crime to withhold decryption keys.
This way the system admins can easily find the IPs of people who abuse the system as well as do logfile analysis.
Generating keys that are really random is also more secure because the keys will not be weak to be easy to remember nor will they be written down anywhere.
Now, I know that UK has a pretty elite history of code breaking. I have also have it on pretty good authority that for high profile cases there is a special place where encrypted data can be sent and it just magically comes back decrypted with no explanation. Speculating on this kind of thing is a guilty pleasure of mine, and frankly this discussion of freedom of the press this, they're journalists not hippy treehuggers that is boring me so here's a couple of points:
1) It's probable -- a no brainer really, that government and law enforcement in the UK do have massive farms of computers to crack passwords and they routinely use them. It is a fact that most people who use encryption don't really know how it works and don't really appreciate how crucial it is to use really strong keys.
2) The PC was not designed with cryptography in mind. People blissfully believe laptops are secure with their cryptographic filesystems at the same time they use the hibernate feature which writes the contents of the memory, including keys, to disk. Recovering those keys is now easy. Another side channel attack may be against the main memory. Who says all the data is gone when the machine is unplugged. There may be good ways of recovering that data thus recovering the key. There are products which handle cryptographic operations in hardware and have some kind of protected storage for keys. I assume this storage is memory mapped so that the kernel doesn't need to ever store the key in actual RAM anywhere, but I haven't investigated those kind of solutions so I don't want to be talking out of my ass too much about them. Think about it though... entering a key in with the keyboard via a userland program... how many buffers is that data going to get stored in? This problem is non-trivial. Lets see... the key ends up on the stack of the application at least twice, then when we go into kernel mode via a system call I suppose we can just copy it directly from there into the hardwares address... then we should probably overwrite the location(s) in RAM with random data a whole bunch of times...
Then we can worry about side channel attacks against the "tamper resistant" memory of the crypto hardware. Cause hey, all those super tamperproof commerical devices are perfect right?? Like smartcards! right?
In conclusion, I don't really buy into the theory that big governments can crack the crypto itself. Instead I think they can do it when it's used improperly (examples: Enigma operators who reused keys, suspects who use words based on their hobbies as keys) and when that doesn't work they get down to the electrical/mechanical level and recover the key that way.
Slashdot Mirror
Is it OpenBSD that is keeping you safe, or is it that you have the wisdom to avoid running sketchy programs on your computer combined with the fact that there isn't much malware for OpenBSD out there waiting for you to run?
If we entered the twilight zone and imagine that OpenBSD was the dominent player in the consumer OS market we would still have tons of zombies doing bad things. Sure, thanks to ProPolice, W^X, and Guard Pages bugs in MSN and Outlook Express for OpenBSD would be less exploitable than is the case in Windows right now. None of these things help when users run programs sent by their worm infected friends. Nothing in OpenBSD prevents programs from debugging other processes running as the same user and modifying them on the fly either.
And even in an alternate universe it's questionable if making the legacy-binary-breaking changes required by these features would have allowed it to remain the dominant OS.
OpenBSD is really cool. The latest release brings some great new features. It's now possible to have a *fully* redundant firewall/vpn box. (support for keeping filter, nat, queue, ipsec states sync'd on all nodes, support for takeover of failed device, support for interface trunking for layer2 redundancy...) It works very well and it's a snap to setup since everything is in the default install. Mark Uemura is giving a talk about this at PacSec this november in Tokyo. Here are slides from an older one he did.
> longer dealing with computers but with people
> and if you piss them off to much they will be
> less then helpful.
If you ever find yourself being accused of not practicing responsible disclosure you can take comfort in the fact that you cannot be responsible for everyone's needs. The term "responsible disclosure" doesn't include the part about who you are supposed to be responsible for, that's up to you to decide.
In my humble opinion, the correct way to disclose a bug is however you feel like doing it. You found it. You don't owe anybody for that. Maybe you believe that the fastest route to a more secure and reliable world of software is if people who choose to use certain software are punished as often as possible so that they switch to software written by a more responsible party. Who knows? Maybe it could work. It is definitely not immoral or irresponsible to believe this since we don't know what does work. If there was one obvious true way to make a hole public (or not) that had no ill effects then everyone would be doing that already. duh.
If a researcher, with no prior contact with the vendor posts a vulnerability out of the blue then the people who work at the vendor are going to be pissed. They are going to call the researcher "irresponsible", but that's only because they have to maintain a certain amount of class. They really just think he's an asshole because he is going out of his way to make things harder than they need to be for the developers and the customers who use the software.
I do not think many researchers are acting this way.
On the flipside, when researchers contact a vendor in good faith and that vendor treats them badly then it is unreasonable for the vendor to expect any more good faith efforts from that researcher.
As you so aptly pointed out, having tact is key. If the researcher does a vendor the courtesy of giving advanced notice, and he is open and honest about his motovations and expectations, whatever they are, then I say he is responsible.
examples:
A researcher who found bug by fuzzing, currently has _no evidence_ that it is being exploited giving a heads up to the vendor:
"hi I just found this remotely exploitable heap overflow in WizBang. All versions starting from 2.1 are vulnerable. You can reproduce this bug by blah blah blah. I plan to discuss this during my presentation at PacSec, a security conference that focuses on new research which is being held in Japan on November 15th. You should make sure you have patches ready before then. let me know if you need any more info."
It doesn't matter at all if the vendor really can't fix the problem before then, because it is a major design flaw requiring huge rewrite that will screw over the release schedule for the next 6 months. The vendor may say this and try to stall, then call the researcher "irresponsible" when he follows through and goes public, but it's nothing more than selfish whining. When someone who you don't even know offers you something highly valueable for free you are in no position to start making demands. It is utterly mind boggling how certain companies try to justify behaving this way.
In this example the researcher is being responsible for himself and his career by making it known to vendors who believe they are ultimately responsible for finding their own bugs that he would be worthy of hiring. Or he's making it know that his company has smart people who can find and exploit bugs, not a bunch of monkeys who charge money for running nessus. Either one thing that sure ISN'T his concern is making sure the vendor can patch in time. No amount of vendor temper tantrums can force him to take on that responsibility. How is it even possible to be responsible for the actions of a bunch of programmers who don't even work for you???
Here's another example of responsible disclosure that's sure to draw flames.
A couple
I'm tired of these commercials I see on TV that advertise some DVD. they all say, in that voice, you know the one:
"OWN IT TODAY ON DVD"
It should be illegal for them to say that. It's false advertising. If I could actually "own it on dvd" then I could make as many copies as I please. say what you will about piracy of music and movies, but before you give these fuckers the moral highground how about they start telling the TRUTH and say,
"LICENSE IT TODAY ON DVD"
yeah, doesn't quite have the same ring to it, huh?
SPF^H^H^HSenderID. The whole attach senders IP to their domain with a new DNS record idea may or may not be good, but in either case microsoft patented methods already existing in SPF, offered a license incompatable with free software, then insinuated they would take action against implementers. They used a trivial patent to derail the hard work of many people.
maybe, just maybe, in the entire world, there are a handful software ideas each year that are worthy of a patent.
I think RSA for example was a worthy invention. 20 years is also way too long for software. 5 years is more reasonable.
I saw a talk by a guy named David Maynor back in May. Here's the USB vulnerability presentation which includes the details of the vulnerability.
it's fairly similar to the firewire problem.
I really think they are lying about not keeping IP addresses in logs at all. If I were the UK police I would have been running for a search warrent as soon as they said "we don't have that data". like FAST. Cause they probably deleted it which means the sooner I can get my hands on that drive the less work it will be to get my clues off it.
The net is so spammy these days. How when some jerk posts a tons of crap to their site how do they know his IP address to ban him? Leave tcpdump outputting to a console and have a real good memory? I don't think so. Apperently they were banning by IP. (go ahead, correct me if that's not true of that particular IM site) Most likely they stored the usual access_log but they deleted it frequently.. or at least they thought they did. It is utterly impossible to delete data from magnetic media. If you are trying to hide something from the police it better not *ever* have been written to disk in plaintext.
They should have bought a fresh hard drive and copied the files over from the old one (cp -a or tar, but not dd!) and then taken a hammer to the original, and thrown it in a ramdom dumpster. If it was ever found they could claim "oh that drive was already dead" and because it won't spin correctly any more cost of forensics on it is through the roof. Then they could have said "sure detective, I'd be happy to help. Why don't you bring a hard drive with you at least X gigs and we can make you an image"
At least by storing it in a RAM disk like the parent suggests the data will get overwritten many times over short periods of time which will surely make forensics more difficult.
Swap is just as easy to encrypt. For swap you always just create a crypto loop device with a random key at startup, create a new swap space on it and enable. OpenBSD can do this internally. It's trivial with all other free unix systems.
There is no point in encrypting the system or the content since that is all public anyway. At issue here are the logs - and yes, there are logs otherwise how would they go about banning based on IP address as stated in the Wikipedia article about them?
The correct solution here is to have the system create a random key upon startup and create a fresh filesystem where the logs will be stored. If the system is seized and powered off for cold anaylsis then the key will be lost. Not even the system admins would know it - and if they don't know it they can't be held liable for it even if the UK does consider it a crime to withhold decryption keys.
This way the system admins can easily find the IPs of people who abuse the system as well as do logfile analysis.
Generating keys that are really random is also more secure because the keys will not be weak to be easy to remember nor will they be written down anywhere.
Now, I know that UK has a pretty elite history of code breaking. I have also have it on pretty good authority that for high profile cases there is a special place where encrypted data can be sent and it just magically comes back decrypted with no explanation. Speculating on this kind of thing is a guilty pleasure of mine, and frankly this discussion of freedom of the press this, they're journalists not hippy treehuggers that is boring me so here's a couple of points:
1) It's probable -- a no brainer really, that government and law enforcement in the UK do have massive farms of computers to crack passwords and they routinely use them. It is a fact that most people who use encryption don't really know how it works and don't really appreciate how crucial it is to use really strong keys.
2) The PC was not designed with cryptography in mind. People blissfully believe laptops are secure with their cryptographic filesystems at the same time they use the hibernate feature which writes the contents of the memory, including keys, to disk. Recovering those keys is now easy. Another side channel attack may be against the main memory. Who says all the data is gone when the machine is unplugged. There may be good ways of recovering that data thus recovering the key. There are products which handle cryptographic operations in hardware and have some kind of protected storage for keys. I assume this storage is memory mapped so that the kernel doesn't need to ever store the key in actual RAM anywhere, but I haven't investigated those kind of solutions so I don't want to be talking out of my ass too much about them. Think about it though... entering a key in with the keyboard via a userland program... how many buffers is that data going to get stored in? This problem is non-trivial. Lets see... the key ends up on the stack of the application at least twice, then when we go into kernel mode via a system call I suppose we can just copy it directly from there into the hardwares address... then we should probably overwrite the location(s) in RAM with random data a whole bunch of times...
Then we can worry about side channel attacks against the "tamper resistant" memory of the crypto hardware. Cause hey, all those super tamperproof commerical devices are perfect right?? Like smartcards! right?
In conclusion, I don't really buy into the theory that big governments can crack the crypto itself. Instead I think they can do it when it's used improperly (examples: Enigma operators who reused keys, suspects who use words based on their hobbies as keys) and when that doesn't work they get down to the electrical/mechanical level and recover the key that way.
My favorite winner was from a few years ago..."Stanley looked quite bored and somewhat detached, but then penguins often do.
/Sean/
--