Who says that FoxConn is not just going to take the extra money as profit rather than give that money in the form of raises? The country is horribly corrupt at government and company levels.
Apple's just paying lip service.
I have to wonder whether the modern western world can only survive on slavery, with outsourcing being a convenient way to hide it.
This is great progress, because it means that lesbian mothers will eventually be able to have children that are genetically related to both parents. This would mean that all their children are female, but they may not mind.
I was intrigued by the./ posting, which claimed that the tutorial would show how to exploit any NULL pointer dereference. The actual article, however, requires a CALL to the NULL pointer. While some NULL pointer bugs are function pointers, many are not. Kernel code that merely reads or writes data to a NULL pointer will not be exploitable as shown.
But sometimes, they can still be exploited. Let's hypothesize a UNIX clone whose kernel has this code in its implementation of the chroot() system call, something that only root should be able to call:
Now let's suppose that there is a bug in the kernel that you can exploit to cause get_current_process() to return a null process pointer. Using mmap(), you can allocate the zero page. The get_current_process()->m_uid expression now reads memory that you control. Of course, you're going to put 0 at that location.
With chroot() available to a non-root program, it will only be a matter of a few tricks with setuid programs before you get root access. Once you have root access, you can elevate to full kernel mode by loading a kernel extension.
Like Linux, the NT kernel exists in the same address space as applications, so the same concepts apply. To map the null 64k of address space as valid memory, call either VirtualAlloc or MapViewOfFileEx (*). Passing NULL as your desired mapping address to these functions normally means that you want Windows to find an available virtual address for you. To get around that, pass (void*)1. This works because NT will round down to the nearest allocation boundary (64k for new allocations).
What does this say about WoW, if it can be played quite successfully by a bot?
I'm sure that many NP-hard problems exist in WoW. Obviously, farming gold and leveling are not NP-hard. But other questions such as, "Can this raid boss be defeated?" would be extremely difficult in the general case.
Something that hasn't really been mentioned yet is that in NP-hard games played by humans, the difficulty has been dumbed down for humans. The versions played by humans have a very small problem space (Tetris, Sudoku) or avoid the nasty cases that are NP-hard (Picross). Some others like Minesweeper avoid nasty cases by randomness: the nasty cases are simply unlikely.
The fix for the KiTrap0D V86 bug was really simple and straightforward. The below explanation is for XP, but it's likely similar for all versions.
A previously unused byte field, KTHREAD::Spare0[0], has been repurposed as a flag indicating whether a call out to the PC (or VGA) BIOS is in progress on that thread in V86 mode. V86 mode in 32-bit NT is used not just to emulate DOS programs, but also to make calls to the PC and VGA BIOS for things like setting the video mode. Of course, these calls to the BIOS are privileged while virtualized DOS programs are not. The security hole was that the general protection fault handler for V86 mode (part of KiTrap0D) did not properly distinguish between faults coming from BIOS calls and faults coming from virtual DOS programs.
The new flag is set by Ki386SetupAndExitToV86Code, which is called by Ke386CallBios, when the kernel is attempting to do a BIOS call. KiTrap0D now only allows the BIOS return call mechanism, which led to the privileged escalation, to be called when that flag is set.
If this change causes people's computers to crash, it probably means that there is kernel code that calls the BIOS in some way than the usual way, and Microsoft didn't account for that. Such code could be part of the kernel, supporting drivers, or third-party device drivers.
I have severe depression, and have suicidal thoughts pretty much every day. I use the Web and WoW to escape from my persistent gender dysphoria. In chat rooms and online games, I can be a girl, but not in real life.
MASM abstracts too much for my tastes. MASM does a lot of things automatically that you don't necessarily want, and it's irritating. Also, it is sometimes context-sensitive: "mov eax, meow" differs in meaning in MASM depending on whether "meow" is a variable or a label. The former means to read the value stored in "meow" (mov eax, [meow]), and the other means to load the address of "meow" (mov eax, offset meow).
Also, MASM code frequently uses things like ".IF" statements to build conditional blocks for you.
NASM and the clone YASM take a far different approach: they do exactly what you tell them to. "mov eax, meow" always means to load the address of "meow" into eax. NASM and YASM also have many ways to specify exactly which encoding to use for your construction when it is ambiguous. For example, you can say "add eax, byte 4" (83 C0 04) or "add eax, dword 4" (05 04 00 00 00). I'm not sure, but it might even be possible to use the longer variant (81 C0 04 00 00 00).
If you're coding in assembly language, it's probably because you need detailed control of the processor for some operation that must be exactly the way you specify. If you don't need that level of detail, you should do yourself and everyone else a favor and use C.
Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.
We recently bought servers with their cryptography performance as a huge factor in our decision. The primary math operation required for SSL, modular exponentiation, is extremely expensive in CPU use. It is still the #1 item on CPU profiling charts for the servers.
We actually went to 64-bit just to get the 2x~3x modular exponentiation performance it provides.
Also, this CPU cost won't really go down: if you can buy faster machines, so can the crackers. So you increase the key size.
Darwin Awards don't really follow that anymore. After all, two of the top dishonors this year went to people who were already removed from the gene pool: a Catholic priest, and a fifty-year-old woman.
In the video game Breath of Fire 2, the enemy of the game is the god of an obviously Catholic-like church. This god is actually a demon, and has tricked all its followers into worshiping him.
Breath of Fire 2 was released in the US during the heyday of the SNES, and it's very surprising to me that Nintendo let the game through their censorship policies of the day with such obvious anti-religious overtones. The churches in the game even had priests and nuns.
140 DLL characteristics
Dynamic base
NX compatible
Acrobat was linked with the/DYNAMICBASE and/NXCOMPAT linker options. This means that on Windows Vista and 7, the executable is loaded at a random address and NX is enabled. The DLLs are all loaded at random addresses too. Does the exploit still work with those countermeasures?
I'm surprised it wasn't used more often, but there's a better way with modems to prevent problems with +++ and NO CARRIER.
With proper settings, the serial line CD (Carrier Detect) is raised when the modem is connected, and lowered when it disconnects. Also with proper settings, if the computer lowers the TR (Terminal Ready) serial line, the modem will hang up.
With this, you can do ATS2=255 or something like that to disable the +++ system. Then you can send any data you want, because the connection control is out-of-band.
This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever. I don't feel that it's necessary to use digital signatures to secure the system.
The fundamental flaw of DNS is that the "nonce" - the one-time-use random constant used to prevent spoofing - is only 16 bits. If you're going to change the DNS protocol, why not just increase the size of that field to 64 bits and be done with it? Then it's only a software change to DNS servers rather than an expensive certificate and far less of an administrative headache.
Also, I don't think that it's even necessary to change the protocol. The protocol allows for multiple DNS queries in one packet. When doing a DNS query, ask for both www.google.com and a nonce domain like eujrdyhtaeoym.example.com. If the query comes back saying that eujrdyhtaeoym.example.com does not exist (or even if it says it does!), you know nobody is spoofing DNS queries back at you because unless they were snooping traffic, they wouldn't have a way to know that your nonce was eujrdyhtaeoym.
You log into your bank account using an unprivileged process. Firefox doesn't run with Administrator access. This means that a non-Administrator Trojan can steal your bank account password without so much as a UAC dialog coming up.
Making your machine a zombie in a botnet doesn't require Administrator access either, assuming that the back door listens on a port higher than 1023.
Sure, it might be easier to clean, assuming you know it's there. Most of the viruses I run into that are stealing our customers' credentials aren't even detected by the anti-virus companies yet.
The numbers they are distributing are the prime factors of the RSA key used by the calculators. The factors were determined by a general number field sieve calculation; this was effective because the keys are only 512 bits long.
The public key itself - the modulus - might be subject to copyright. However, the prime factors were never copied from TI - they were mathematically determined from the modulus. Attacking them because they distribute numbers mathematically derived from a copyrighted number is new legal territory.
If numbers derived from a calculation on a copyrightable number are themselves "derivative works" in the copyright sense, it would cause far-reaching problems well beyond calculators. For one thing, it would be illegal to distribute SHA-1 hashes of copyrighted material without permission.
In reading this post, I'm trying to understand what is being complained about. In my understanding of the situation, having handled this update for my employer's projects, this is what happens:
You release version 1.0 of a product using VC 2005 SP1 before the update. Version 1.0 therefore depends on version 762 of the DLL. You install the security update on your build machine. You release version 1.1 of your product as an update. Version 1.1 depends on version 4053 of the DLL because it was compiled on a build machine with the security update installed. Your customers install version 1.1 of your product without installing the runtime update from Microsoft. The program doesn't start because customers don't have the version that 1.1 depends on, 4053.
The same thing occurred when SP1 was released, yet there weren't many complaints then. I think it's more of a lack of education on how this DLL versioning stuff works. It was widespread knowledge that SP1-compiled programs needed a newer runtime. My employer's product doesn't even embed the DLL installer (vcredist_x64.exe); instead, we just dump the raw files and.manifest file into the application's local directory. Interestingly, even though the 762 DLLs are in that local directory, Windows will automatically load 4053 from the WinSxS directory if you have the security update installed.
The moral of the story is if you install the update on your build server, you need to have your customers update as well. Do the right thing and have your update program install it for them, or alternatively shove the files into the local application directory for the same effect.
Slashdot Mirror
I'm a decently-paid male programmer who is in the middle of transition to becoming a woman. I also was diagnosed with Asperger's syndrome.
I wonder what this sort of thing means for me... >.<
To go to America and find out who killed his father and why. And get past the level with those !@#$ing hawks.
Who says that FoxConn is not just going to take the extra money as profit rather than give that money in the form of raises? The country is horribly corrupt at government and company levels.
Apple's just paying lip service.
I have to wonder whether the modern western world can only survive on slavery, with outsourcing being a convenient way to hide it.
This is great progress, because it means that lesbian mothers will eventually be able to have children that are genetically related to both parents. This would mean that all their children are female, but they may not mind.
I was intrigued by the ./ posting, which claimed that the tutorial would show how to exploit any NULL pointer dereference. The actual article, however, requires a CALL to the NULL pointer. While some NULL pointer bugs are function pointers, many are not. Kernel code that merely reads or writes data to a NULL pointer will not be exploitable as shown.
But sometimes, they can still be exploited. Let's hypothesize a UNIX clone whose kernel has this code in its implementation of the chroot() system call, something that only root should be able to call:
if (get_current_process()->m_uid != 0)
{
return EPERM;
}
Now let's suppose that there is a bug in the kernel that you can exploit to cause get_current_process() to return a null process pointer. Using mmap(), you can allocate the zero page. The get_current_process()->m_uid expression now reads memory that you control. Of course, you're going to put 0 at that location.
With chroot() available to a non-root program, it will only be a matter of a few tricks with setuid programs before you get root access. Once you have root access, you can elevate to full kernel mode by loading a kernel extension.
The concept of a null pointer kernel vulnerability works in Windows too.
Like Linux, the NT kernel exists in the same address space as applications, so the same concepts apply. To map the null 64k of address space as valid memory, call either VirtualAlloc or MapViewOfFileEx (*). Passing NULL as your desired mapping address to these functions normally means that you want Windows to find an available virtual address for you. To get around that, pass (void*)1. This works because NT will round down to the nearest allocation boundary (64k for new allocations).
* The real system calls are actually NtAllocateVirtualMemory and NtMapViewOfSection, respectively.
What does this say about WoW, if it can be played quite successfully by a bot?
I'm sure that many NP-hard problems exist in WoW. Obviously, farming gold and leveling are not NP-hard. But other questions such as, "Can this raid boss be defeated?" would be extremely difficult in the general case.
Something that hasn't really been mentioned yet is that in NP-hard games played by humans, the difficulty has been dumbed down for humans. The versions played by humans have a very small problem space (Tetris, Sudoku) or avoid the nasty cases that are NP-hard (Picross). Some others like Minesweeper avoid nasty cases by randomness: the nasty cases are simply unlikely.
Rupert's mantra should probably be listen to what I say, (pay no attention to what I do)
Isn't that the mantra of "the Right" in general?
I for one can't wait until quantum computers destroy all current forms of public-key cryptography and end all these signing systems.
They could go with Lamport signatures, but those are terribly inconvenient to work with.
The fix for the KiTrap0D V86 bug was really simple and straightforward. The below explanation is for XP, but it's likely similar for all versions.
A previously unused byte field, KTHREAD::Spare0[0], has been repurposed as a flag indicating whether a call out to the PC (or VGA) BIOS is in progress on that thread in V86 mode. V86 mode in 32-bit NT is used not just to emulate DOS programs, but also to make calls to the PC and VGA BIOS for things like setting the video mode. Of course, these calls to the BIOS are privileged while virtualized DOS programs are not. The security hole was that the general protection fault handler for V86 mode (part of KiTrap0D) did not properly distinguish between faults coming from BIOS calls and faults coming from virtual DOS programs.
The new flag is set by Ki386SetupAndExitToV86Code, which is called by Ke386CallBios, when the kernel is attempting to do a BIOS call. KiTrap0D now only allows the BIOS return call mechanism, which led to the privileged escalation, to be called when that flag is set.
If this change causes people's computers to crash, it probably means that there is kernel code that calls the BIOS in some way than the usual way, and Microsoft didn't account for that. Such code could be part of the kernel, supporting drivers, or third-party device drivers.
I have severe depression, and have suicidal thoughts pretty much every day. I use the Web and WoW to escape from my persistent gender dysphoria. In chat rooms and online games, I can be a girl, but not in real life.
MASM abstracts too much for my tastes. MASM does a lot of things automatically that you don't necessarily want, and it's irritating. Also, it is sometimes context-sensitive: "mov eax, meow" differs in meaning in MASM depending on whether "meow" is a variable or a label. The former means to read the value stored in "meow" (mov eax, [meow]), and the other means to load the address of "meow" (mov eax, offset meow).
Also, MASM code frequently uses things like ".IF" statements to build conditional blocks for you.
NASM and the clone YASM take a far different approach: they do exactly what you tell them to. "mov eax, meow" always means to load the address of "meow" into eax. NASM and YASM also have many ways to specify exactly which encoding to use for your construction when it is ambiguous. For example, you can say "add eax, byte 4" (83 C0 04) or "add eax, dword 4" (05 04 00 00 00). I'm not sure, but it might even be possible to use the longer variant (81 C0 04 00 00 00).
If you're coding in assembly language, it's probably because you need detailed control of the processor for some operation that must be exactly the way you specify. If you don't need that level of detail, you should do yourself and everyone else a favor and use C.
I see your x86 absolute value trick and raise you my MIPS absolute value trick:
bgtz a0, label
label:
subu a0, zero, a0
Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.
We recently bought servers with their cryptography performance as a huge factor in our decision. The primary math operation required for SSL, modular exponentiation, is extremely expensive in CPU use. It is still the #1 item on CPU profiling charts for the servers.
We actually went to 64-bit just to get the 2x~3x modular exponentiation performance it provides.
Also, this CPU cost won't really go down: if you can buy faster machines, so can the crackers. So you increase the key size.
Darwin Awards don't really follow that anymore. After all, two of the top dishonors this year went to people who were already removed from the gene pool: a Catholic priest, and a fifty-year-old woman.
In the video game Breath of Fire 2, the enemy of the game is the god of an obviously Catholic-like church. This god is actually a demon, and has tricked all its followers into worshiping him.
Breath of Fire 2 was released in the US during the heyday of the SNES, and it's very surprising to me that Nintendo let the game through their censorship policies of the day with such obvious anti-religious overtones. The churches in the game even had priests and nuns.
From AcroRd32.exe's PE header:
Acrobat was linked with the /DYNAMICBASE and /NXCOMPAT linker options. This means that on Windows Vista and 7, the executable is loaded at a random address and NX is enabled. The DLLs are all loaded at random addresses too. Does the exploit still work with those countermeasures?
I'm surprised it wasn't used more often, but there's a better way with modems to prevent problems with +++ and NO CARRIER.
With proper settings, the serial line CD (Carrier Detect) is raised when the modem is connected, and lowered when it disconnects.
Also with proper settings, if the computer lowers the TR (Terminal Ready) serial line, the modem will hang up.
With this, you can do ATS2=255 or something like that to disable the +++ system. Then you can send any data you want, because the connection control is out-of-band.
This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever. I don't feel that it's necessary to use digital signatures to secure the system.
The fundamental flaw of DNS is that the "nonce" - the one-time-use random constant used to prevent spoofing - is only 16 bits. If you're going to change the DNS protocol, why not just increase the size of that field to 64 bits and be done with it? Then it's only a software change to DNS servers rather than an expensive certificate and far less of an administrative headache.
Also, I don't think that it's even necessary to change the protocol. The protocol allows for multiple DNS queries in one packet. When doing a DNS query, ask for both www.google.com and a nonce domain like eujrdyhtaeoym.example.com. If the query comes back saying that eujrdyhtaeoym.example.com does not exist (or even if it says it does!), you know nobody is spoofing DNS queries back at you because unless they were snooping traffic, they wouldn't have a way to know that your nonce was eujrdyhtaeoym.
Would this utility be useless if you lock your computer when you get up from it? If so, the criminally-minded among us should do that.
If it works even with the computer locked, it implies a Microsoft back door into Windows. I doubt this.
You log into your bank account using an unprivileged process. Firefox doesn't run with Administrator access. This means that a non-Administrator Trojan can steal your bank account password without so much as a UAC dialog coming up.
Making your machine a zombie in a botnet doesn't require Administrator access either, assuming that the back door listens on a port higher than 1023.
Sure, it might be easier to clean, assuming you know it's there. Most of the viruses I run into that are stealing our customers' credentials aren't even detected by the anti-virus companies yet.
This was long ago identified to have a genetic basis, known as "a second X chromosome".
Microsoft Word is a very long number, yet nobody disputes its copyright.
The numbers they are distributing are the prime factors of the RSA key used by the calculators. The factors were determined by a general number field sieve calculation; this was effective because the keys are only 512 bits long.
The public key itself - the modulus - might be subject to copyright. However, the prime factors were never copied from TI - they were mathematically determined from the modulus. Attacking them because they distribute numbers mathematically derived from a copyrighted number is new legal territory.
If numbers derived from a calculation on a copyrightable number are themselves "derivative works" in the copyright sense, it would cause far-reaching problems well beyond calculators. For one thing, it would be illegal to distribute SHA-1 hashes of copyrighted material without permission.
In reading this post, I'm trying to understand what is being complained about. In my understanding of the situation, having handled this update for my employer's projects, this is what happens:
You release version 1.0 of a product using VC 2005 SP1 before the update. Version 1.0 therefore depends on version 762 of the DLL.
You install the security update on your build machine.
You release version 1.1 of your product as an update. Version 1.1 depends on version 4053 of the DLL because it was compiled on a build machine with the security update installed.
Your customers install version 1.1 of your product without installing the runtime update from Microsoft.
The program doesn't start because customers don't have the version that 1.1 depends on, 4053.
The same thing occurred when SP1 was released, yet there weren't many complaints then. I think it's more of a lack of education on how this DLL versioning stuff works. It was widespread knowledge that SP1-compiled programs needed a newer runtime. My employer's product doesn't even embed the DLL installer (vcredist_x64.exe); instead, we just dump the raw files and .manifest file into the application's local directory. Interestingly, even though the 762 DLLs are in that local directory, Windows will automatically load 4053 from the WinSxS directory if you have the security update installed.
The moral of the story is if you install the update on your build server, you need to have your customers update as well. Do the right thing and have your update program install it for them, or alternatively shove the files into the local application directory for the same effect.