Interesting, and a pretty cool trick that I should try. However, that won't help 32-bit browsers running on 64-bit Windows. You'd either have to always use a 64-bit browser or come up with a segment-less sandbox implementation in 32-bit mode.
Unlike 32-bit Windows, 64-bit Windows does not provide user-mode programs the ability to create arbitrary selectors. NtSetLdtEntries returns STATUS_NOT_IMPLEMENTED in 64-bit Windows. In fact, in Vista 64 and XP 64, the kernel does "xor eax, eax \ lldt ax" and never touches LDTR again. This means that even drivers couldn't create selectors on behalf of user-mode programs, because the Windows scheduler does not save or restore LDTR during a task switch.
This is absolutely core functionality that is necessary in order for this to work - if user mode can't create selectors with shorter limits, Google's design plain doesn't work.
In contrast, even in 64-bit mode, Linux allows modify_ldt() and Mac OS allows i386_set_ldt(). In fact, this functionality is the only reason WINE is possible on these platforms.
What would happen if you tried to express cracking an AES key in 3-SAT form then asked this program to solve it? Will it have to introduce exponentially more variables?
I figure that if anyone claims to have a 3-SAT algorithm, we should ask it to try something infeasible like crack an AES key.
What would you rather have, Israel and the US bombing Tehran, or the CIA and Mossad making a computer virus to disable centrifuges? I think I'll open door #2, thank you very much.
Either way, you have collateral damage; I just think the world is better off with fried OS installations than fried humans.
Maybe Manning spoke at length to Lamo about being a closested homosexual, and the frustrations that came with it, especially being in the military?
Some of the chat logs that are out there have hints from Manning about that. One interpretation of the chat logs, where he says he didn't like the fact that pictures of him would be him "as [a] boy", is that he wishes he were a woman. What would be the point in releasing that information other than to create a sensationalist headline?
Anyone who uses a hash, instead of something asymmetric like RSA, for "signing" doesn't know what they are on about. I would have hoped that Canon could afford better programmers.
It doesn't matter; if you can extract the software inside the camera, you can do anything the camera does. It doesn't matter whether they use SHA, RSA, or ROT-13.
The correct solution would be to put the key in a tamper-resistant hardware cryptographic processor, and secure the firmware on the camera against running unverified code. Canon did neither.
Vista and 7's driver signing requirement is mainly for DRM purposes.
No, the driver signing requirement is for quality control purposes. 60% of Windows crashes used to be driver-related. Now, Microsoft actually requires a proof of correctness, using their Static Driver Verifier, before a driver is signed.
You're talking about the Windows Hardware Quality Labs signature, not the kernel-mode driver signing requirement in 64-bit Vista and 7. A WHQL signature is not required in order to have a driver load, a kernel-mode driver signature is. Microsoft only does their quality testing with drivers submitted to WHQL; an appropriate VeriSign certificate is enough to get the driver to load, without any quality checking on the part of Microsoft.
It is the kernel-mode driver signing requirement that this rootkit bypasses, not the WHQL signature.
Vista and 7's driver signing requirement is mainly for DRM purposes. The main thing Microsoft wanted to stop with driver signing is device drivers that create fake sound cards and video cards that can capture decrypted DRM-protected songs and movies. It doesn't help much with rootkits. This is why if you disable driver signing yourself, Vista and 7 will refuse to play some types of DRM-protected media. For example, some Blu-Ray players.
Rootkits can just attack the boot process to disable the signature checks, as shown here. But there is another way - third party companies don't have the stringent secure coding standards of modern Microsoft, so all you need to do is find a bug in a legitimately signed driver, and you're in. I found a signed Win64 driver that adds IOCTLs to let Administrators set CPU MSRs - you can exploit that by having it set the system call handler address to your own memory, and you're in.
I like how Windows warns you about unsigned device drivers installed the normal way - this is good for users, and helps keep hardware companies in check a little bit. However, removing the right to load unsigned code without disabling part of the OS is unfair.
As a sovereign nation, Iran has the same rights to a top-level domain as any other nation, and in her official language now that it is possible. That she is currently out of favor with the West should be irrelevant.
Besides, don't we want more Internet access for Iranians anyway?
And of course the Americans have shown their importance of preserving monuments such as all the ones in Hiroshima.
Like the alternative of carpet bombing Tokyo for months and a million dead on both sides would have been so much better. When thinking of how America used The Bomb, please consider the otherwise inevitable alternative.
Now we just need the jailbreak team to release a Safari/Preview patch to fix the hole. That way, we won't have to go to 4.0.2 in order to be safe from the PDF exploit, thus locking us out from the jailbreak.
I just hope that someone makes a tool for the jailbreak that patches Preview to fix the same PDF bug that was used to install the jailbreak. I don't want to be forced to use an insecure version (4.0.1) just to have a jailbroken phone.
That's silly. A single core of a 3 GHz i7 is already several times faster than a single core of a 3 GHz Pentium 4.
This cannot continue forever - it's exponential growth in a finite world. I may be wrong about when the limit is reached, but not about whether.
This is incorrect. Not only is it incorrect, but almost every x86 chip produced this century will prove you wrong. See speculative execution and out of order execution, for example.
For this to work, radical processor redesign would be necessary to allow communication and synchronization among cores down to the level of a few machine language instructions.
Direct emulation of the hardware isn't the only option. You can also reimplement the API(s) provided by the console, for which there need not be any noteworthy processing overhead. This is the approach that Wine uses. Of course, this is generally a more labour intensive approach, but for a static API, far from unattainable.
It's not the API that is the problem, it's the instruction set. All three major consoles of this generation have PowerPC CPUs. Wine doesn't have to worry about emulating the instruction set of the source processor, just like WOW64 doesn't. If consoles have the same instruction set as PCs, emulation can and probably will be done.
Give it time. if you think we've peaked our CPU output I think your in for a suprise.
Even if I'm wrong about exactly when emulation has ended or will end, it will end at some point. That is the problem with exponential growth in a finite world.
Emulation is just going to need a re-think. In the future emulators will likely consist of one core doing the converting from ancient to modern while a second core handles the actual execution. In fact, multiple cores could be used to do the converting. As long as at least one core executes native code at the speed of the original you're good to go.
The modern consoles currently out of reach of emulation also have a useful property for anti-piracy / anti-homebrew reasons: they do not allow self-modifying code. This means that only static recompilation is required for emulation. Recompilation to the target machine code can be done offline and take arbitrarily long - it isn't necessary to recompile at execution time.
The problem then reduces to taking a block of code for one processor and converting it to code for another processor of similar speed that runs equally fast or faster. That is very, very difficult.
"Emulation of a serial instruction stream cannot be parallelized in software."
Why not? Don't CPUs do this all the time by having long pipelines and decoding instructions out of order?
True, that is one possibility. However, such a system would require extremely fast communication and synchronization among cores to a granularity of a few assembly instructions, far out of reach in current multicore systems.
Emulation is no longer possible for new consoles. The last console for which a feasible emulator could exist (and in fact does) is probably the Wii.
Emulation requires that the emulating machine be several times faster than the emulated machine, because there is effort required in translating the original assembly code to the target processor's code. For older consoles, this isn't a problem. But consider emulating something like the Xbox 360: a tri-core 3.2 GHz PowerPC. In order to emulate one of the cores of such a system, you need to have a CPU that is several times faster than 3.2 GHz, even with advanced optimizing recompilation.
Such systems do not exist. It comes down to the fact that computers are not getting faster, but getting more parallel instead. Emulation of a serial instruction stream cannot be parallelized in software.
People generations from now will be able to play Contra but not Call of Duty Modern Warfare.
I found a ring 0 exploit in a popular operating system, whereby any unprivileged user-mode process could get ring 0 access. It's been about a month since I told the developer, and they haven't said when a fix would be coming.
It's a ring 0 exploit, but actually turning it into a a root exploit is annoyingly complex due to the design of this operating system. There is nothing computer-theoretic stopping it, just complexity regarding the way page tables work. The exploit gives ring 0 in your control very easily, but the process of getting user-mode root from ring 0 like this is difficult.
I think for the freedom of the software world, we need to solve the discrete logarithm problem. There will never be freedom as long as it is mathematically possible to make digital signatures.
I said when the Xbox 1 came out that the way of the future was for all devices to have this digital signature-based boot loader stuff, now called Trusted Computing. I hate how I'm right so often.
Slashdot Mirror
see http://nativeclient.googlecode.com/svn/data/site/NaCl_SFI.pdf for the sandboxing schemes for x86-64 and arm.
Interesting, and a pretty cool trick that I should try. However, that won't help 32-bit browsers running on 64-bit Windows. You'd either have to always use a 64-bit browser or come up with a segment-less sandbox implementation in 32-bit mode.
Cite?
Unlike 32-bit Windows, 64-bit Windows does not provide user-mode programs the ability to create arbitrary selectors. NtSetLdtEntries returns STATUS_NOT_IMPLEMENTED in 64-bit Windows. In fact, in Vista 64 and XP 64, the kernel does "xor eax, eax \ lldt ax" and never touches LDTR again. This means that even drivers couldn't create selectors on behalf of user-mode programs, because the Windows scheduler does not save or restore LDTR during a task switch.
This is absolutely core functionality that is necessary in order for this to work - if user mode can't create selectors with shorter limits, Google's design plain doesn't work.
In contrast, even in 64-bit mode, Linux allows modify_ldt() and Mac OS allows i386_set_ldt(). In fact, this functionality is the only reason WINE is possible on these platforms.
The Wachowskis aren't brothers anymore. I wish people would stop referring to them as such.
What would happen if you tried to express cracking an AES key in 3-SAT form then asked this program to solve it? Will it have to introduce exponentially more variables?
I figure that if anyone claims to have a 3-SAT algorithm, we should ask it to try something infeasible like crack an AES key.
What would you rather have, Israel and the US bombing Tehran, or the CIA and Mossad making a computer virus to disable centrifuges? I think I'll open door #2, thank you very much.
Either way, you have collateral damage; I just think the world is better off with fried OS installations than fried humans.
Some of the chat logs that are out there have hints from Manning about that. One interpretation of the chat logs, where he says he didn't like the fact that pictures of him would be him "as [a] boy", is that he wishes he were a woman. What would be the point in releasing that information other than to create a sensationalist headline?
Anyone who uses a hash, instead of something asymmetric like RSA, for "signing" doesn't know what they are on about. I would have hoped that Canon could afford better programmers.
It doesn't matter; if you can extract the software inside the camera, you can do anything the camera does. It doesn't matter whether they use SHA, RSA, or ROT-13.
The correct solution would be to put the key in a tamper-resistant hardware cryptographic processor, and secure the firmware on the camera against running unverified code. Canon did neither.
Vista and 7's driver signing requirement is mainly for DRM purposes.
No, the driver signing requirement is for quality control purposes. 60% of Windows crashes used to be driver-related. Now, Microsoft actually requires a proof of correctness, using their Static Driver Verifier, before a driver is signed.
You're talking about the Windows Hardware Quality Labs signature, not the kernel-mode driver signing requirement in 64-bit Vista and 7. A WHQL signature is not required in order to have a driver load, a kernel-mode driver signature is. Microsoft only does their quality testing with drivers submitted to WHQL; an appropriate VeriSign certificate is enough to get the driver to load, without any quality checking on the part of Microsoft.
It is the kernel-mode driver signing requirement that this rootkit bypasses, not the WHQL signature.
Vista and 7's driver signing requirement is mainly for DRM purposes. The main thing Microsoft wanted to stop with driver signing is device drivers that create fake sound cards and video cards that can capture decrypted DRM-protected songs and movies. It doesn't help much with rootkits. This is why if you disable driver signing yourself, Vista and 7 will refuse to play some types of DRM-protected media. For example, some Blu-Ray players.
Rootkits can just attack the boot process to disable the signature checks, as shown here. But there is another way - third party companies don't have the stringent secure coding standards of modern Microsoft, so all you need to do is find a bug in a legitimately signed driver, and you're in. I found a signed Win64 driver that adds IOCTLs to let Administrators set CPU MSRs - you can exploit that by having it set the system call handler address to your own memory, and you're in.
I like how Windows warns you about unsigned device drivers installed the normal way - this is good for users, and helps keep hardware companies in check a little bit. However, removing the right to load unsigned code without disabling part of the OS is unfair.
Microsoft Visual C++ and C# allow Unicode identifiers; that is, variable and function names. Visual C++ allows this:
int meow()
{
int áéíóú = 1;
return áéíóú;
}
As a sovereign nation, Iran has the same rights to a top-level domain as any other nation, and in her official language now that it is possible. That she is currently out of favor with the West should be irrelevant.
Besides, don't we want more Internet access for Iranians anyway?
Like say you buy a Denon receiver. Very high tech gadget with lots of nifty features.
Is that the same Denon as the one that makes high-tech gadgets like $500 ethernet cables?
It makes sense - you drink piss to get pissed.
Compare this to Apple, which still hasn't fixed my Darwin kernel ring 0 exploit, which I reported in June.
It's x86-only, so no, it can't be used for the second step of an iPhone jailbreak. =(
And of course the Americans have shown their importance of preserving monuments such as all the ones in Hiroshima.
Like the alternative of carpet bombing Tokyo for months and a million dead on both sides would have been so much better. When thinking of how America used The Bomb, please consider the otherwise inevitable alternative.
Now we just need the jailbreak team to release a Safari/Preview patch to fix the hole. That way, we won't have to go to 4.0.2 in order to be safe from the PDF exploit, thus locking us out from the jailbreak.
I just hope that someone makes a tool for the jailbreak that patches Preview to fix the same PDF bug that was used to install the jailbreak. I don't want to be forced to use an insecure version (4.0.1) just to have a jailbroken phone.
This cannot continue forever - it's exponential growth in a finite world. I may be wrong about when the limit is reached, but not about whether.
For this to work, radical processor redesign would be necessary to allow communication and synchronization among cores down to the level of a few machine language instructions.
It's not the API that is the problem, it's the instruction set. All three major consoles of this generation have PowerPC CPUs. Wine doesn't have to worry about emulating the instruction set of the source processor, just like WOW64 doesn't. If consoles have the same instruction set as PCs, emulation can and probably will be done.
Give it time. if you think we've peaked our CPU output I think your in for a suprise.
Even if I'm wrong about exactly when emulation has ended or will end, it will end at some point. That is the problem with exponential growth in a finite world.
Emulation is just going to need a re-think. In the future emulators will likely consist of one core doing the converting from ancient to modern while a second core handles the actual execution. In fact, multiple cores could be used to do the converting. As long as at least one core executes native code at the speed of the original you're good to go.
The modern consoles currently out of reach of emulation also have a useful property for anti-piracy / anti-homebrew reasons: they do not allow self-modifying code. This means that only static recompilation is required for emulation. Recompilation to the target machine code can be done offline and take arbitrarily long - it isn't necessary to recompile at execution time.
The problem then reduces to taking a block of code for one processor and converting it to code for another processor of similar speed that runs equally fast or faster. That is very, very difficult.
"Emulation of a serial instruction stream cannot be parallelized in software."
Why not? Don't CPUs do this all the time by having long pipelines and decoding instructions out of order?
True, that is one possibility. However, such a system would require extremely fast communication and synchronization among cores to a granularity of a few assembly instructions, far out of reach in current multicore systems.
Emulation is no longer possible for new consoles. The last console for which a feasible emulator could exist (and in fact does) is probably the Wii.
Emulation requires that the emulating machine be several times faster than the emulated machine, because there is effort required in translating the original assembly code to the target processor's code. For older consoles, this isn't a problem. But consider emulating something like the Xbox 360: a tri-core 3.2 GHz PowerPC. In order to emulate one of the cores of such a system, you need to have a CPU that is several times faster than 3.2 GHz, even with advanced optimizing recompilation.
Such systems do not exist. It comes down to the fact that computers are not getting faster, but getting more parallel instead. Emulation of a serial instruction stream cannot be parallelized in software.
People generations from now will be able to play Contra but not Call of Duty Modern Warfare.
I found a ring 0 exploit in a popular operating system, whereby any unprivileged user-mode process could get ring 0 access. It's been about a month since I told the developer, and they haven't said when a fix would be coming.
It's a ring 0 exploit, but actually turning it into a a root exploit is annoyingly complex due to the design of this operating system. There is nothing computer-theoretic stopping it, just complexity regarding the way page tables work. The exploit gives ring 0 in your control very easily, but the process of getting user-mode root from ring 0 like this is difficult.
I think for the freedom of the software world, we need to solve the discrete logarithm problem. There will never be freedom as long as it is mathematically possible to make digital signatures.
I said when the Xbox 1 came out that the way of the future was for all devices to have this digital signature-based boot loader stuff, now called Trusted Computing. I hate how I'm right so often.