Typically it's unusual to see ``just a crash.'' Most programmes written in C and C++ crash due to buffer overflows, which frequently lead to running unsigned code. As a general rule, if a C or C++ code crashes, it is a fairly likely possibility to be able to run arbitrary code. Just because nobody's done it yet doesn't mean that it's not possible.
If you actually code for a living you should stop right now. (living or coding, either way works for me). The bugs demonstrated here are not buffer overflows. They are the other kind of common C/C++ bug, namely an invalid (in this case NULL) pointer dereference. Null pointer dereferencing bugs are rarely exploitable.
Sorry, but they're not null pointer dereferences, they're both integer errors which cause wacky but non-exploitable behaviour. For those who speak some assembly (clearly nobody in this subthread) the author's analysis can be found here:
People are extrapolating the actions of a small group of hateful idiots to an entire class of people who happen to have an overlapping characteristic and disparaging the entire group as stupid, backward, or violent.
You mean like we do with Muslims?
Flu Pandemic - What To Do (no, really)
on
A Flu Pandemic?
·
· Score: 4, Insightful
There is a lot of speculation in this thread, and very little of it seems to be from public health practitioners. Every major health organisation in the world has actually thought about this problem, so you could go and google their FAQs and advice pages if you want, but let me summarise.
1. H5N1 is not a pandemic virus. The scary thing is a mutation of H5N1. Forget about the statistical wrangling over 50%. The morbidity (deatharifficness) of the human cases is based on small numbers, and a human-to-human strain could have different characteristics in any case. Just accept that the current concern is real and that random computer programmers do not "know better".
2. PLEASE don't try and buy up Tamiflu. You don't know what to do with it, you don't know how to diagnose flu properly and it's needed elsewhere. If you think you, or someone else has something which you think should be treated with Tamiflu GET TO A FRICKING HOSPITAL. If it's the correct treatment they will have it.
3. IMPORTANT: If you are "at risk" of initial infection of H5N1 (professional chicken-kisser etc etc) or you are a high-risk flu group (old, asthma, child etc) then GET A FLU JAB for seasonal influenza.
Note: This will not do anything to stop you getting H5N1 (sorry), although it may (unproven) help you survive. The idea is that if you don't get "normal" flu in the first place then there is less chance of you getting H5N1 _at the same time_, which could result in in-cell reassortment (genetic mutation) of the virus. In other words, H5N1 could cross with whatever flu you got to make a new flu. That could then result in you being patient zero for the killer-flu we're all scared of. (which would suck)
4. If you want to be ultra-paranoid, you could postpone non-essential travel to, eg, SE Asia or put off your "All Eastern Europe Cockfighting" tour. Your call.
5. Frankly, for the majority here I doubt that there is anything in particular you should be doing differently right now. BUT just keep a weather eye on the news - if ever the pandemic hits then these recommendations will instantly be out the window and people will be talking about masks, quarantine and emergency plans.
The sky is NOT currently falling. It is fair odds that unless you happen to indulge in "the love that dare not speak its name" with poultry or enjoy fresh duck's blood soup then there's not much you can do - the sky will fall or it won't. However, the reason health agencies are making a lot of noise is that _were_ the sky to fall, right now, global preparedness is not as good as it could be.
Sorry, you have no idea what you are talking about. First of all, NX doesn't really have much to do with stack buffer overflows in particular - you'd normally mark the heap as NX too - you are thinking (and here I give you the benefit of the doubt) of the Stackguard-like protection (stack canary) with which all SP2+ apps are compiled. Anyway, NX is only relevent with processors that support that flag.
Secondly, SP2 contains a BUNCH of useful technologies which are actually specifically designed to make heap overflow exploitation more difficult. These include PEB randomisation (make PEB overwrites harder), safe unlinking (no more unlinking pointer copies -> arbirary overwrite -> root) and chunk header cookies (like stack cookies).
Oh, yeah, and DLLs aren't loaded into the heap. They're loaded at their preferred address and reloated by the loader if required.
This particular problem is a heap overrun, not a stack overflow. XPSP2 introduced major changes to the way heap memory is laid out.
The improvements included safe unlinking, randomising the base address of the PEB (makes it harder to overwrite the UEF for example), and a heap version of a stack canary called a security cookie.
There are also improvements to the stack security by using a stack canary a la StackGuard compiled in by default for all MS apps.
Basically SP2 does contain a bunch of actual, measurable improvements to the way writeable memory is dealt with. It's not bulletproof but it will screw most 'stock' exploits.
By the way, something that nobody will tell you about BOFRA is that there _is_ a workaround - you can disable active scripting. The exploit uses javascript to allocate masses of heap memory to 'seed' the heap ready for the exploit. This is NOT a fix for all possible ways to attack this bug, just a fix for this particular attack.
The comment section in a JPG image can have a length. The smallest valid length is 2 (no comments, but the field is still 2 bytes wide).
If you manually make this length 0 then the length gets normalised by subtracting 2 to -2, which, when converted ends up as 0xfffffffe, ie a very big number.
That number eventually gets passed to memcpy, which totally clobbers the heap. After that, the actual exploitation gets long and complex. If you know a lot about windows memory management structures, just look up the guy's advisory (not the MS one) then check out some books on exploiting heap overflows.
These kinds of hard-to-automatically-check integer errors are the root cause for lots of vulnerabilities these days, as vanilla stack buffer overflows decline.
Not only is the concept stupid, but I looked at the guy's thesis for five seconds and his crypto is totally broken - there is a trivial known plaintext attack to recover the secret password if you can intercept knocks on the wire. The plaintext is [IP addr][port][action] for 4 + 2 + 1 bytes each. The last byte is pad - which is cunningly hardwired to null.
The IP address makes up 4 bytes of a 7 byte plaintext (which is already small enough to brute force) and the IP address will be that of the knocking host. Wait, it gets worse! The "action" byte is basically "open" or "close" and the port bytes don't quite use the full 2^16 range. In other words I need to brute force a little less than 17 bits. This is only challenging if I want to make like ET and do it with a reprogrammed Speak N Spell.
There is basically zero security reason to use anything like this to access legit services - just run a secure service in the first place. If you need to only access it from certain locations use a firewall or tcpwrappers. If you need authenticated access then use a VPN or SSH. These are all much better scrutinised approaches than some crappy daemon which somebody just...um...knocked up.
Remember that if it's a legitimate service then somebody should weigh the security value (in this case bugger all) against the potential risk introduced by adding a brand new service which is going to need significant privileges to run (given that it executes commands to open ports or change firewall rules.)
Where this _is_ amazingly useful is to hide services like rootkits and zombie-control interfaces from automated port and vulnerability scanners. This method is already used in some rootkits to avoid detection.
In summary, this is only useful when concealment is the key objective - it doesn't add any security per se. cf "security by obscurity" and "welcome to clueville".
Michael Surkan has also sent a similar survey request to a lot of security mailing lists, asking about the future of network security. A quick google for him suggests that he really does have the job at MS he says he has, and the email he used to post to firewall-wizards checks out.
Personally, I'm a little alarmed to now read this article and see what _else_ he's gathering info on...
CERN also happens to be physically located here near Geneva, and the local language is french. It's lovely and all that lots of the organisations use English as their official language, but it's also useful to be able to go shopping, talk to your landlord, order dinner etc.
I have been involved with lots of different bits of security for a few years now, and quite a few people seem to think I know what I'm doing.
Playing the "security component Lego" game is great fun, and a little intelligent thought will soon see you set up with a nice, best-practice architecture. This is how it will then fail.
1. You will have unpatched machines which will be trivially rooted with a script-kiddie exploit. You will know that you should have patched, but you won't have the time, manpower, or authority to ensure the patches are in place.
2. You will misconfigure something, and then miss the problem in reviews because you didn't get peer or professional verification of all your configs.
3. You will get owned by an internal employee who has exactly the level of trust that you planned for, but abused it.
4. Someone will walk in with a clipboard, bamboozle the secretary and walk out with your fileserver.
5. You will create a whole bunch of really cool procedures, but the CIO / CTO won't back them when the first departments complain about lost productivity - this will undermine the whole thing and you will be back at square one.
6. You will give someone VPN access, and they will connect their virus and worm ridden home machine. It will infect your network, and their kids will surf pr0n and share mp3s on your dime.
7. Your backups will have some unforseen problem, your restore procedures won't work right because they aren't tested, and you will lose much company data (and your job).
8. Your users will deliberately download trojan-ridden, virus infected, IE Object Overflow infested garbage, despite clear, explicit orders to the contrary being sent to them twice a day. They will do this because dancing rabbits are somehow more compelling than 'all those emails from the grumpy tech guys'.
When we talk about the 'current paradigms', I don't even think about fancy technology, I think about these obvious threats that always apparently only happen to other people, because some wiseguy always knows better. "IF you do blah blah, like we do..."
Your "paradigm" wish might be: "I want a network where every single part is doing as best it can to defend itself against the threat at the keyboard as well as the threat from external attack - not a perimeter, not 'tiers', but every part."
Nice idea, but every single worthwhile encryption algorithm is basically uncrackable by looking at 'word patterns'.
Even if you look at Really Really Old And Bad algorithms like Ceasar and Vignere (rot13 is a ceasar cipher example), changing the letter ordering doesn't change the frequency count (how often each letter is used) which will mean that simple frequency analysis will work Just Fine. I wrote a really dumb perl script once to automatically crack ceasar and vignere ciphers just by matching 'standard' frequencies to cipher frequencies - no need to even look at 'patterns' for readability. You only need a few lines of cipher, for simple ones.
(yes, crypto geeks will know that there are extra steps involved in the vignere cipher, to work out the periodicity)
Please read the paper. The key to this attack is the selection of different multiplication algorithms depending on the lengths of the words being multiplied. Then, depending on the algorithm, the timing attack is based on whether the ciphertext is larger, smaller, or a multiple of the secret RSA moduli. Your explanation is a little too oversimplified.
RSA blinding doesnt mess with the timings, actually. All it does is multiply in a random number to the ciphertext before decryption and then divide it out later. It defeats these kind of attacks nicely because the attacker cant control the ciphertext that is actually getting fed into the RSA algorithms. There is a fixed (rather than random) performance penalty.
As I've mentioned before: The laws of Physics are against this. Nuclear bombs work on cities. In the countryside, a 100 Megaton bomb does surprisingly little damage. The damage spreads only about 15 miles from the center of the blast
I admire the rest of your sentiments, but you're really wrong about the above.
I've read several of the UN reports on the effects of Nuclear Weapons, which tend to use a 1Mt (ONE. Not One hundred.) device as an example. Even with a single 1Mt airburst, "immediate" fallout can deliver a lethal dose of radiation for something like a hundred miles, depending on prevailing winds. This effect is directly proportional to the size of the blast. That means that we're talking about an uncontrollable swathe of lethal windborne dirt hundreds of miles in length.
This is NOT "surprisingly little damage".
For weapons of this size, most of the immediate deaths in a desert detonation will be from blast and heat. The lethal range for direct radiation exposure would be well inside the lethal blast radius.
The "standard" fallout (much smaller particles) will tend not to be radioactive enough to kill people in the short term, but a detonation of a 100Mt device would have effects that are, quite simply, incalculable - increased cancer risks, birth defects, increased infection rates for just about everything - you name it. The fallout will darken skies in the region for days.
While we're in a happy mood, it is also possible for the explosion to trigger spontaneous precipitation, called a "rain out", which would happily kill anyone that got wet.
Now, the war-guys will be talking about tac-nukes, in the few hundred kiloton range. They'll ask you to believe that the damage will be localised. The truth is that they have no idea, and the independant research strongly suggests otherwise.
Believe me - the damage from a nuclear detonation cannot be contained in either time or space, and it's infeasible that the damage could be restricted to military target. Hell, it's infeasible that it could be restricted to one COUNTRY, in that region.
Leo is a Sprout Faced boy. Say no more. Let's face it though, we're all going to go and see it even if it does have him in it - just like we're all going to go and see Episode 1 even if it gets absolutely rubbish reviews.
Perhaps they plan to implement some sort of watermark in the music that will survive the MP3 encryption process? Then the phase 2 software on the device (or the software that uploads music to the device) will search for this watermarking in the digital file; if it detects the watermark, it won't allow the upload.
Slashdot Mirror
Typically it's unusual to see ``just a crash.'' Most programmes written in C and C++ crash due to buffer overflows, which frequently lead to running unsigned code. As a general rule, if a C or C++ code crashes, it is a fairly likely possibility to be able to run arbitrary code. Just because nobody's done it yet doesn't mean that it's not possible.
3 0/threaded
If you actually code for a living you should stop right now. (living or coding, either way works for me).
The bugs demonstrated here are not buffer overflows. They are the other kind of common C/C++ bug, namely an invalid (in this case NULL) pointer dereference. Null pointer dereferencing bugs are rarely exploitable.
Sorry, but they're not null pointer dereferences, they're both integer errors which cause wacky but non-exploitable behaviour. For those who speak some assembly (clearly nobody in this subthread) the author's analysis can be found here:
http://www.securityfocus.com/archive/1/421257/30/
People are extrapolating the actions of a small group of hateful idiots to an entire class of people who happen to have an overlapping characteristic and disparaging the entire group as stupid, backward, or violent.
You mean like we do with Muslims?
There is a lot of speculation in this thread, and very little of it seems to be from public health practitioners. Every major health organisation in the world has actually thought about this problem, so you could go and google their FAQs and advice pages if you want, but let me summarise.
1. H5N1 is not a pandemic virus. The scary thing is a mutation of H5N1. Forget about the statistical wrangling over 50%. The morbidity (deatharifficness) of the human cases is based on small numbers, and a human-to-human strain could have different characteristics in any case. Just accept that the current concern is real and that random computer programmers do not "know better".
2. PLEASE don't try and buy up Tamiflu. You don't know what to do with it, you don't know how to diagnose flu properly and it's needed elsewhere. If you think you, or someone else has something which you think should be treated with Tamiflu GET TO A FRICKING HOSPITAL. If it's the correct treatment they will have it.
3. IMPORTANT: If you are "at risk" of initial infection of H5N1 (professional chicken-kisser etc etc) or you are a high-risk flu group (old, asthma, child etc) then GET A FLU JAB for seasonal influenza.
Note: This will not do anything to stop you getting H5N1 (sorry), although it may (unproven) help you survive. The idea is that if you don't get "normal" flu in the first place then there is less chance of you getting H5N1 _at the same time_, which could result in in-cell reassortment (genetic mutation) of the virus. In other words, H5N1 could cross with whatever flu you got to make a new flu. That could then result in you being patient zero for the killer-flu we're all scared of. (which would suck)
4. If you want to be ultra-paranoid, you could postpone non-essential travel to, eg, SE Asia or put off your "All Eastern Europe Cockfighting" tour. Your call.
5. Frankly, for the majority here I doubt that there is anything in particular you should be doing differently right now. BUT just keep a weather eye on the news - if ever the pandemic hits then these recommendations will instantly be out the window and people will be talking about masks, quarantine and emergency plans.
The sky is NOT currently falling. It is fair odds that unless you happen to indulge in "the love that dare not speak its name" with poultry or enjoy fresh duck's blood soup then there's not much you can do - the sky will fall or it won't. However, the reason health agencies are making a lot of noise is that _were_ the sky to fall, right now, global preparedness is not as good as it could be.
Thanks.
Sorry, you have no idea what you are talking about. First of all, NX doesn't really have much to do with stack buffer overflows in particular - you'd normally mark the heap as NX too - you are thinking (and here I give you the benefit of the doubt) of the Stackguard-like protection (stack canary) with which all SP2+ apps are compiled. Anyway, NX is only relevent with processors that support that flag.
Secondly, SP2 contains a BUNCH of useful technologies which are actually specifically designed to make heap overflow exploitation more difficult. These include PEB randomisation (make PEB overwrites harder), safe unlinking (no more unlinking pointer copies -> arbirary overwrite -> root) and chunk header cookies (like stack cookies).
Oh, yeah, and DLLs aren't loaded into the heap. They're loaded at their preferred address and reloated by the loader if required.
Apart from that, good post. Well done.
IE on 2K is vulnerable. Switch browsers. :)
This particular problem is a heap overrun, not a stack overflow. XPSP2 introduced major changes to the way heap memory is laid out.
The improvements included safe unlinking, randomising the base address of the PEB (makes it harder to overwrite the UEF for example), and a heap version of a stack canary called a security cookie.
There are also improvements to the stack security by using a stack canary a la StackGuard compiled in by default for all MS apps.
Basically SP2 does contain a bunch of actual, measurable improvements to the way writeable memory is dealt with. It's not bulletproof but it will screw most 'stock' exploits.
By the way, something that nobody will tell you about BOFRA is that there _is_ a workaround - you can disable active scripting. The exploit uses javascript to allocate masses of heap memory to 'seed' the heap ready for the exploit. This is NOT a fix for all possible ways to attack this bug, just a fix for this particular attack.
Specifics:
The comment section in a JPG image can have a length. The smallest valid length is 2 (no comments, but the field is still 2 bytes wide).
If you manually make this length 0 then the length gets normalised by subtracting 2 to -2, which, when converted ends up as 0xfffffffe, ie a very big number.
That number eventually gets passed to memcpy, which totally clobbers the heap. After that, the actual exploitation gets long and complex. If you know a lot about windows memory management structures, just look up the guy's advisory (not the MS one) then check out some books on exploiting heap overflows.
These kinds of hard-to-automatically-check integer errors are the root cause for lots of vulnerabilities these days, as vanilla stack buffer overflows decline.
Not only is the concept stupid, but I looked at the guy's thesis for five seconds and his crypto is totally broken - there is a trivial known plaintext attack to recover the secret password if you can intercept knocks on the wire. The plaintext is [IP addr][port][action] for 4 + 2 + 1 bytes each. The last byte is pad - which is cunningly hardwired to null.
The IP address makes up 4 bytes of a 7 byte plaintext (which is already small enough to brute force) and the IP address will be that of the knocking host. Wait, it gets worse! The "action" byte is basically "open" or "close" and the port bytes don't quite use the full 2^16 range. In other words I need to brute force a little less than 17 bits. This is only challenging if I want to make like ET and do it with a reprogrammed Speak N Spell.
Back to sleep for me until version 5.0.
There is basically zero security reason to use anything like this to access legit services - just run a secure service in the first place. If you need to only access it from certain locations use a firewall or tcpwrappers. If you need authenticated access then use a VPN or SSH. These are all much better scrutinised approaches than some crappy daemon which somebody just...um...knocked up.
Remember that if it's a legitimate service then somebody should weigh the security value (in this case bugger all) against the potential risk introduced by adding a brand new service which is going to need significant privileges to run (given that it executes commands to open ports or change firewall rules.)
Where this _is_ amazingly useful is to hide services like rootkits and zombie-control interfaces from automated port and vulnerability scanners. This method is already used in some rootkits to avoid detection.
In summary, this is only useful when concealment is the key objective - it doesn't add any security per se. cf "security by obscurity" and "welcome to clueville".
Well, it's almost certainly not a hoax.
Michael Surkan has also sent a similar survey request to a lot of security mailing lists, asking about the future of network security. A quick google for him suggests that he really does have the job at MS he says he has, and the email he used to post to firewall-wizards checks out.
Personally, I'm a little alarmed to now read this article and see what _else_ he's gathering info on...
CERN also happens to be physically located here near Geneva, and the local language is french. It's lovely and all that lots of the organisations use English as their official language, but it's also useful to be able to go shopping, talk to your landlord, order dinner etc.
I have been involved with lots of different bits of security for a few years now, and quite a few people seem to think I know what I'm doing.
Playing the "security component Lego" game is great fun, and a little intelligent thought will soon see you set up with a nice, best-practice architecture. This is how it will then fail.
1. You will have unpatched machines which will be trivially rooted with a script-kiddie exploit. You will know that you should have patched, but you won't have the time, manpower, or authority to ensure the patches are in place.
2. You will misconfigure something, and then miss the problem in reviews because you didn't get peer or professional verification of all your configs.
3. You will get owned by an internal employee who has exactly the level of trust that you planned for, but abused it.
4. Someone will walk in with a clipboard, bamboozle the secretary and walk out with your fileserver.
5. You will create a whole bunch of really cool procedures, but the CIO / CTO won't back them when the first departments complain about lost productivity - this will undermine the whole thing and you will be back at square one.
6. You will give someone VPN access, and they will connect their virus and worm ridden home machine. It will infect your network, and their kids will surf pr0n and share mp3s on your dime.
7. Your backups will have some unforseen problem, your restore procedures won't work right because they aren't tested, and you will lose much company data (and your job).
8. Your users will deliberately download trojan-ridden, virus infected, IE Object Overflow infested garbage, despite clear, explicit orders to the contrary being sent to them twice a day. They will do this because dancing rabbits are somehow more compelling than 'all those emails from the grumpy tech guys'.
When we talk about the 'current paradigms', I don't even think about fancy technology, I think about these obvious threats that always apparently only happen to other people, because some wiseguy always knows better. "IF you do blah blah, like we do..."
Your "paradigm" wish might be: "I want a network where every single part is doing as best it can to defend itself against the threat at the keyboard as well as the threat from external attack - not a perimeter, not 'tiers', but every part."
Nice idea, but every single worthwhile encryption algorithm is basically uncrackable by looking at 'word patterns'.
Even if you look at Really Really Old And Bad algorithms like Ceasar and Vignere (rot13 is a ceasar cipher example), changing the letter ordering doesn't change the frequency count (how often each letter is used) which will mean that simple frequency analysis will work Just Fine. I wrote a really dumb perl script once to automatically crack ceasar and vignere ciphers just by matching 'standard' frequencies to cipher frequencies - no need to even look at 'patterns' for readability. You only need a few lines of cipher, for simple ones.
(yes, crypto geeks will know that there are extra steps involved in the vignere cipher, to work out the periodicity)
You have a breast account and a penis account?
Eww. Squishy.
Ím sorry, but thats just crap.
Please read the paper. The key to this attack is the selection of different multiplication algorithms depending on the lengths of the words being multiplied. Then, depending on the algorithm, the timing attack is based on whether the ciphertext is larger, smaller, or a multiple of the secret RSA moduli. Your explanation is a little too oversimplified.
RSA blinding doesnt mess with the timings, actually. All it does is multiply in a random number to the ciphertext before decryption and then divide it out later. It defeats these kind of attacks nicely because the attacker cant control the ciphertext that is actually getting fed into the RSA algorithms. There is a fixed (rather than random) performance penalty.
I admire the rest of your sentiments, but you're really wrong about the above.
I've read several of the UN reports on the effects of Nuclear Weapons, which tend to use a 1Mt (ONE. Not One hundred.) device as an example. Even with a single 1Mt airburst, "immediate" fallout can deliver a lethal dose of radiation for something like a hundred miles, depending on prevailing winds. This effect is directly proportional to the size of the blast. That means that we're talking about an uncontrollable swathe of lethal windborne dirt hundreds of miles in length.
This is NOT "surprisingly little damage".
For weapons of this size, most of the immediate deaths in a desert detonation will be from blast and heat. The lethal range for direct radiation exposure would be well inside the lethal blast radius.
The "standard" fallout (much smaller particles) will tend not to be radioactive enough to kill people in the short term, but a detonation of a 100Mt device would have effects that are, quite simply, incalculable - increased cancer risks, birth defects, increased infection rates for just about everything - you name it. The fallout will darken skies in the region for days.
While we're in a happy mood, it is also possible for the explosion to trigger spontaneous precipitation, called a "rain out", which would happily kill anyone that got wet.
Now, the war-guys will be talking about tac-nukes, in the few hundred kiloton range. They'll ask you to believe that the damage will be localised. The truth is that they have no idea, and the independant research strongly suggests otherwise.
Believe me - the damage from a nuclear detonation cannot be contained in either time or space, and it's infeasible that the damage could be restricted to military target. Hell, it's infeasible that it could be restricted to one COUNTRY, in that region.
Please, please. Do not think about nukes.
Once you have the lines, how about this?
Maybe they're cryptic (as in crossword) clues
Maybe they're rearrangeable (anagram puzzle)
etc,
Good luck
(US resident bastards ;)
PS: My lines are...
This is a truly strange deception
funky are destined to want appendices (??)
He had great marks for the easiest execution of enemy explosions
People need the bestselling conflict in the information age
The suitable specialist offers steps for secure source
ciao
Leo is a Sprout Faced boy. Say no more. Let's face it though, we're all going to go and see it even if it does have him in it - just like we're all going to go and see Episode 1 even if it gets absolutely rubbish reviews.
Perhaps they plan to implement some sort of watermark in the music that will survive the MP3 encryption process? Then the phase 2 software on the device (or the software that uploads music to the device) will search for this watermarking in the digital file; if it detects the watermark, it won't allow the upload.