Must say though, if I were Adobe, staking my reputation on the reliability of some of the highest exposure software on the web, one of the first tasks after the acquisition would have been a thorough review of the Flash client codebase.
Not that this vulnerability would necessarily have been picked up...
I was wondering about this - how does System File Protection not detect the change to Utilman.exe.
Or is SFP only active whilst Windows is running, which would seem to defeat the point of it? (e.g. any Windows dual boot scenario can wreck system files, without even bringing a non-Windows OS into the equation.)
But, as the article points out, you will be able to modify the system to compromise it to such a level that you can take a copy of the BitLocker private key next time it is used.
Physical access is always the end of the game.
It requires something like 360's hypervisor to prevent this, and then gaining physical access to the actual die, without destroying it, could render this useless.
We can only hope that with an exploit against a target with such an enormous installed base, opening up multiple platforms to remote code execution will lead to enough press that other vendors realise the steps they need to take sooner rather than later.
Let's hope more vendors than just Adobe learn their lessons from this one!
Anyone know what the right thing to run browsers with reduced privelegs on Linux actually is? Is this a feature of SELinux?
I have not checked, however I think the chances are that Flash would link to one or more calls you could use as a stepping stone to get the calls you need.
For example, the attacker being able to take the function addresses from the fixed up imports somewhere within the unrelocated Flash binary, rather than trying to call the function directly.
If you try the beta, you will actually notice a significant reduction in the memory used over previous versions.
However, as one of the other replies mentions, it is partly down to the caching, which has now been adjusted. If you are in the "I would rather have a slow browser with no cache" crowd, you can actually tune the cache down in the prefs.
Sorry, the spelling / grammer nazi in me cannot refrain from pointing out that in the singular, it is "an alumnus". "Alumni" is only the plural form. Though you're not an English Language major, so maybe we can forgive!:)
Of course, protesting those assisting the RIAA would be a terrible state of affairs!;)
I believe the revocation threat is against keys used to interact with other organisations, if you gain access to the revocation certs for public keys used to perform eg inter-bank transactions, once those revocation certificates are issued to whichever authority is controlling the key infrastructure (normally only done in the case of a compromised key) then the required level of trust is no longer present, leading to failed transactions whilst we race around trying to inform everyone the revocation is false.
I would suggest that is probably the least likely threat addressed in the article though. In the real world, most of these systems have a selection of keys to try, where each of the private parts and the revocations are stored on diverse hardware with unique security around each of them.
I think the threat most likely to face an average user is having one of your private keys compromised without knowing it has happened.
Given the way crypto hardware works though, this should be near impossible for serious organisations using "real" crypto solutions.
Except when they screw the hardware up...
I believe they are referring to keys in situations where the keys are used to encrypt / decrypt business critical data, rather than say SSL certificates.
Error tolerance refers to pixel errors in the output image compared to a reference rendering.
eg, the fast texture sampling methods on gaming cards lead to aliasing errors, where the pixel is in error compared to a refernce rendering.
There are also a lot more factors to this than just floating point precision, for example how the edges of polys are treated, how part-transparent textures are treated and how textures are sampled and blended.
You're right - fire is absolutely fascinating, but I find it very hard to put my finger on what it is that makes it so exciting.
Amateur pyrotechnics is definitely a lot of fun. It is a bit of a shame that due to the changes in society today, and the culmination of a lot of anti-social behaviour, it is now quite expensive and difficult to buy the required chemicals.
I would love to play more with burning things, but have nowhere nearby to do so safely and without causing alarm!
I think you mean 1 part aluminium powder with 2 parts iron oxide.
The aluminium takes the oxygen from the iron oxide, releasing the sigificant amount of energy and leaving the unoxidised iron. If the aluminium was already oxidised, this would not happen.
Otherwise, yes - excellent idea. I even have a broken HDD I need to wipe, thanks!
It is normally not a PC though, there are dedicated AV control systems out there (AMX, Crestron et al). Being a control systems programmer, I happen to know many of the sets at trade shows, especially AV trade shows, are under RS232 control!
Often this is because of the impracticality of the remote - many only have a single on/off button on the IR remote. You press it, half of the displays turn off. You press it again, some of the display toggle from on to off, some toggle from off to on. You end up using a rolled up sheet of paper to go around each one to set it on / off.
Unfortunately not many of the models have the ability to lock the IR out via the serial port!
That is never going to happen though - nothing pushes corporate developers to work with the standards.
Dev: "So, what browser are we going to use?" Corp: "Well, we run Windows on the desktop, so Internet Explorer is already installed. Plus all our other in-house uses IE" Dev: "Have you considered Firefox? We can make it standards compliant, then you can use any browser!" Corp: "You were outbid, the low bidder is only testing against the platform we use, IE."
1) The RNG being completely unpredictable is the very basis of many encryption algorithms. Often, any, even a very small weakness in the RNG decreases the strength of an algorithm by a factor much higher than the slight loss of randomness. For example, it may means you only have to attack a small block of the output, as you have can narrow down the possible values of the remainder of the block. It basically allows you to take educated guesses as to the state of the RNG later in the block, giving you a much smaller space to attack.
2) these errors could reveal data in an encryption algorithm. For example, in the simplest case, if you have a list of possible states, and you see a particular set of values come out that would only be possible in circumstances where the bug has been triggered, you then know extra information about the data that went in. In crypto, ANY slight known deviation from the algorithm will essentially decrease the keyspace. It means you know more about the data that went into the algorithm in the first place than you should.
3) The microcode updates requires priveleged instructions to execute. It requires the equivalent of driver-level access. If it has this, there's no need to play with the microcode, you already have full access.
The microcode update system can only be a good thing, provided that the hardware does only allow privelged access to it, which in all of the released Intel and AMD processors to date, has been correctly implemented.
The only way I see of it being better by not existing is that the hardware might get deeper testing before release. Experience says this is unlikely, as time is a crucial factor in the current processor arms race.
Given that microcode update exists, it means that when flaws are inevitably found, they can be patched, rather than being stuck with a broken, potentially insecure machine. The situation is very like the "oh no, PS3 and 360 games are now going to be as badly tested as PC games, because they can be patched" argument.
1) is a serious problem though. We can never PROVE it is backdoored unless someone steps forward with those numbers.
We can NEVER prove it is NOT backdoored, as we cannot PROVE that no-one has the numbers, so are compelled to treat it as backdoored.
2) is about specific cases where particular categories of mathematical failures actually lead to the compromising of the private key, which is significantly more dangerous. It is not about utilitising typical exploits like buffer overflows to take over and kind of security software. For example, once they private key is known, it may allow the third party to fake messages appearing to originate from the target of the attack.
3) indeed, the problem here is typically relating to very specific edge conditions, eg overflows, underflows, carries which are handled incorrectly, and have been known to go undetected for years. If you do not believe there are issues in the microcode, take a quick look at the current errata list for the Core2Duo, showing many unfixed bugs (and many of them unimportant due to the impossibility of them occurring in modern operating systems).
As for "installing bad microcode", the microcode is something done purely from the software each time the OS boots into volatile memory on the cpu, and so is reset back to the original shipping microcode each time the machine is power-cycled.
If an adversary has access to the booting OS to update the microcode, the adversary already has access to superuser priveleges on your system anyway, so I feel it is irrelevant.
If you can spoof the Blizzard server, there are much larger issues anyway. Post a fake game update, there are many other avenues of attack if you can reach this point.
Slashdot Mirror
Must say though, if I were Adobe, staking my reputation on the reliability of some of the highest exposure software on the web, one of the first tasks after the acquisition would have been a thorough review of the Flash client codebase.
Not that this vulnerability would necessarily have been picked up...
I was wondering about this - how does System File Protection not detect the change to Utilman.exe.
Or is SFP only active whilst Windows is running, which would seem to defeat the point of it? (e.g. any Windows dual boot scenario can wreck system files, without even bringing a non-Windows OS into the equation.)
But, as the article points out, you will be able to modify the system to compromise it to such a level that you can take a copy of the BitLocker private key next time it is used.
Physical access is always the end of the game.
It requires something like 360's hypervisor to prevent this, and then gaining physical access to the actual die, without destroying it, could render this useless.
I run X-WRT / OpenWRT on a WRT54G, which pleasingly is Linux 2.2 based and certainly has full IPTables support!
(The 2.4 based OpenWRT seems to have a problem with the WiFi card - anyone know more?)
We can only hope that with an exploit against a target with such an enormous installed base, opening up multiple platforms to remote code execution will lead to enough press that other vendors realise the steps they need to take sooner rather than later.
Let's hope more vendors than just Adobe learn their lessons from this one!
Anyone know what the right thing to run browsers with reduced privelegs on Linux actually is? Is this a feature of SELinux?
I have not checked, however I think the chances are that Flash would link to one or more calls you could use as a stepping stone to get the calls you need.
For example, the attacker being able to take the function addresses from the fixed up imports somewhere within the unrelocated Flash binary, rather than trying to call the function directly.
If you try the beta, you will actually notice a significant reduction in the memory used over previous versions.
However, as one of the other replies mentions, it is partly down to the caching, which has now been adjusted.
If you are in the "I would rather have a slow browser with no cache" crowd, you can actually tune the cache down in the prefs.
But with NoScript it's not so much surfing as paddling through the mud!
Sorry, the spelling / grammer nazi in me cannot refrain from pointing out that in the singular, it is "an alumnus". "Alumni" is only the plural form. :)
;)
Though you're not an English Language major, so maybe we can forgive!
Of course, protesting those assisting the RIAA would be a terrible state of affairs!
I believe the revocation threat is against keys used to interact with other organisations, if you gain access to the revocation certs for public keys used to perform eg inter-bank transactions, once those revocation certificates are issued to whichever authority is controlling the key infrastructure (normally only done in the case of a compromised key) then the required level of trust is no longer present, leading to failed transactions whilst we race around trying to inform everyone the revocation is false.
I would suggest that is probably the least likely threat addressed in the article though. In the real world, most of these systems have a selection of keys to try, where each of the private parts and the revocations are stored on diverse hardware with unique security around each of them.
I think the threat most likely to face an average user is having one of your private keys compromised without knowing it has happened. Given the way crypto hardware works though, this should be near impossible for serious organisations using "real" crypto solutions. Except when they screw the hardware up...
I believe they are referring to keys in situations where the keys are used to encrypt / decrypt business critical data, rather than say SSL certificates.
Error tolerance refers to pixel errors in the output image compared to a reference rendering.
eg, the fast texture sampling methods on gaming cards lead to aliasing errors, where the pixel is in error compared to a refernce rendering.
There are also a lot more factors to this than just floating point precision, for example how the edges of polys are treated, how part-transparent textures are treated and how textures are sampled and blended.
You're right - fire is absolutely fascinating, but I find it very hard to put my finger on what it is that makes it so exciting.
Amateur pyrotechnics is definitely a lot of fun. It is a bit of a shame that due to the changes in society today, and the culmination of a lot of anti-social behaviour, it is now quite expensive and difficult to buy the required chemicals.
I would love to play more with burning things, but have nowhere nearby to do so safely and without causing alarm!
I think you mean 1 part aluminium powder with 2 parts iron oxide.
The aluminium takes the oxygen from the iron oxide, releasing the sigificant amount of energy and leaving the unoxidised iron.
If the aluminium was already oxidised, this would not happen.
Otherwise, yes - excellent idea. I even have a broken HDD I need to wipe, thanks!
It is normally not a PC though, there are dedicated AV control systems out there (AMX, Crestron et al).
Being a control systems programmer, I happen to know many of the sets at trade shows, especially AV trade shows, are under RS232 control!
Often this is because of the impracticality of the remote - many only have a single on/off button on the IR remote.
You press it, half of the displays turn off.
You press it again, some of the display toggle from on to off, some toggle from off to on.
You end up using a rolled up sheet of paper to go around each one to set it on / off.
Unfortunately not many of the models have the ability to lock the IR out via the serial port!
That is never going to happen though - nothing pushes corporate developers to work with the standards.
Dev: "So, what browser are we going to use?"
Corp: "Well, we run Windows on the desktop, so Internet Explorer is already installed. Plus all our other in-house uses IE"
Dev: "Have you considered Firefox? We can make it standards compliant, then you can use any browser!"
Corp: "You were outbid, the low bidder is only testing against the platform we use, IE."
Seconded, I just got an Asus P5KC motherboard, and on the box and boot screen it says "Rock Solid. Heart touching"!
1) The RNG being completely unpredictable is the very basis of many encryption algorithms.
Often, any, even a very small weakness in the RNG decreases the strength of an algorithm by a factor much higher than the slight loss of randomness. For example, it may means you only have to attack a small block of the output, as you have can narrow down the possible values of the remainder of the block. It basically allows you to take educated guesses as to the state of the RNG later in the block, giving you a much smaller space to attack.
2) these errors could reveal data in an encryption algorithm. For example, in the simplest case, if you have a list of possible states, and you see a particular set of values come out that would only be possible in circumstances where the bug has been triggered, you then know extra information about the data that went in. In crypto, ANY slight known deviation from the algorithm will essentially decrease the keyspace. It means you know more about the data that went into the algorithm in the first place than you should.
3) The microcode updates requires priveleged instructions to execute. It requires the equivalent of driver-level access. If it has this, there's no need to play with the microcode, you already have full access.
The microcode update system can only be a good thing, provided that the hardware does only allow privelged access to it, which in all of the released Intel and AMD processors to date, has been correctly implemented.
The only way I see of it being better by not existing is that the hardware might get deeper testing before release. Experience says this is unlikely, as time is a crucial factor in the current processor arms race.
Given that microcode update exists, it means that when flaws are inevitably found, they can be patched, rather than being stuck with a broken, potentially insecure machine. The situation is very like the "oh no, PS3 and 360 games are now going to be as badly tested as PC games, because they can be patched" argument.
1) is a serious problem though. We can never PROVE it is backdoored unless someone steps forward with those numbers. We can NEVER prove it is NOT backdoored, as we cannot PROVE that no-one has the numbers, so are compelled to treat it as backdoored.
2) is about specific cases where particular categories of mathematical failures actually lead to the compromising of the private key, which is significantly more dangerous. It is not about utilitising typical exploits like buffer overflows to take over and kind of security software. For example, once they private key is known, it may allow the third party to fake messages appearing to originate from the target of the attack.
3) indeed, the problem here is typically relating to very specific edge conditions, eg overflows, underflows, carries which are handled incorrectly, and have been known to go undetected for years. If you do not believe there are issues in the microcode, take a quick look at the current errata list for the Core2Duo, showing many unfixed bugs (and many of them unimportant due to the impossibility of them occurring in modern operating systems).
As for "installing bad microcode", the microcode is something done purely from the software each time the OS boots into volatile memory on the cpu, and so is reset back to the original shipping microcode each time the machine is power-cycled.
If an adversary has access to the booting OS to update the microcode, the adversary already has access to superuser priveleges on your system anyway, so I feel it is irrelevant.
Mislabelled, the larger green one is Ignignokt, Err is the smaller pink one!
But still, a great image - thanks!
If they have the intelligence to sign the game updates, you would hope the communication channel for Warden is also signed?
If you can spoof the Blizzard server, there are much larger issues anyway.
Post a fake game update, there are many other avenues of attack if you can reach this point.
By successfully completing the "set up" stage of arranging the release of a new open algorithm by a third party?
I thought the duress key usually unlocked a second "innocent" set of data stored in the same volume along with other redundant random data?
e.g. I am thinking of the Hidden Volumes feature of TrueCrypt here.
You missed the irony, dumbass.
See the other previous response which you have clearly neglected to read.
Care to enlighten us as to what a "flaim" is then?
Deliberate you say? Why not misspell trool too? And maybe redandant?