The Register article has a bit more information. This isn't really a vulnerability. It's definitely not "remote code execution". It works like this:
- Microsoft provides a tool called AppLocker that can be used to limit the programs that can be run on a system. - The AppLocker tool is not intended as a tight "security boundary". Instead, it is a way to implement company policies like "no playing games at work", or to help with software licensing, i.e. "the company system image has a copy of Photoshop, but you aren't in the Design department, so you aren't licensed to run it", and perhaps to reduce attack surface area. - The Microsoft-provided sample AppLocker configuration (intended to show the syntax for AppLocker rules) happens to have a sample rule that whitelists all programs under C:\windows. This is not a "recommended" rule -- it's a "sample" rule. - If you leave this rule in, there are a large number of ways to escape the sandbox. - A researcher found another one. Yay, I guess?
The new one is interesting because I wouldn't have considered regsvr32 to be a command that allows for running of arbitrary other commands. On the other hand, it shouldn't belong in a production whitelist in the first place, so being able to use it to escape the sandbox isn't particularly interesting.
Whether Kinect is a failure depends on exactly how you define success.
-- Controlling the games we're used to playing on the xbox? FAIL. -- Getting good reviews from people who review games on our favorite gaming websites? FAIL. -- Selling a lot of units? WIN. -- Has some games that some consumers really like? WIN. -- Good as an input mechanism for some interesting non-traditional uses? WIN. -- The future of gaming? FAIL. -- The future of computer-human interaction? PROBABLY.
As an additional note, the first version isn't terribly awesome, but inevitably it'll get better in the future.
One addition is that it is more likely nowadays than ever before for a really messed-up person to survive long enough to provide a contribution to society. Once upon a time, people that saw the world differently were more likely to be abandoned by parents, killed by peers, or starve to death as beggars. Nowadays, geeks are more likely than ever before to find a few people that understand them and are willing to give them a job, turning their unique attributes to good ends. Where geeks used to be lucky to avoid being executed for heresy, nowadays they can make a good living and sometimes even become rich and famous.
A few relevant thoughts come to mind.
First, all greatness depends on insanity. The sane come up with an interesting idea, start thinking about it, see a lot of hard work and little chance for reward, and give it up before it gets very far. The insane pursue the idea to the bitter end. 99% (or more) of the time, "the bitter end" means self-destruction and disappointment. 1% (or less) of the time, the result is something truly great that pushes science/art/civilization/whatever forward another tiny step. Sometimes it is both -- many important innovations were only seen as good long after the innovator had been punished for the crime of innovating.
Second, similar but not quite the same as the first, is a saying that I'm probably going to misquote. "The rational man adapts himself to fit into his surroundings. The irrational man persists in trying to adapt his surroundings to fit himself. Therefore, all progress depends on the irrational man." Unmentioned here is that 99.9% of the time, the irrational man will fail and will be harmed due to his efforts while 99.9% of the time the rational man will thrive or at least survive.
If you pay full price for Windows, you get full rights. Microsoft is willing to give you a discount if you accept more limited terms. Most people are ok with the limited terms and are therefore very happy to accept the discount. If you don't like those terms, you have the option of not buying the product.
I think it is a little bit interesting that Microsoft has divided the market between x86 and ARM differently than it has divided the market between x86 and amd64. In theory, you could have a general-purpose ARM-based server, desktop, or notebook. And in theory, you could have an x86-based tablet. So in theory, Microsoft should be adding "Windows 8 tablet edition for x86", "Windows 8 tablet edition for ARM", "Windows 8 Professional for ARM", and "Windows 8 Server for ARM" to its lineup. However, theory never quite matches up with reality.
In reality, of the editions listed above, only "Windows 8 tablet edition for ARM" is likely to have any market at all in the next 2 years, so Microsoft is probably not going to offer the other 3 editions. When the market changes (e.g. if ARM servers really take off), Microsoft will add editions as necessary for Windows 9. If Intel takes over the tablet market, there will certainly be a Windows 9 tablet edition for x86. And your guess is as good as mine about which of these editions will require secure boot.
I don't think it is accurate to say that "any ARM device that ships with Windows 8 will never run another operating system unless...". First, it should be changed to "any ARM device with the 'Designed for Windows 8' logo will never run another operating system unless..." since it isn't the presence of Windows 8 that determines the status of secure boot. Second, the "unless..." part is pretty important and should be emphasized. Just as Microsoft will be able to sign Windows, other organizations will be able to sign their own operating systems. And hacking/jailbreaking will always happen. So it is more accurate to say "any ARM device with the 'Designed for Windows 8' logo will have to be jailbroken before it can run any unsigned operating system".
In any case, it seems that Microsoft's rules here are the most open of any tablet manufacturer. Can you install your own copy of Linux on an iPad? No. Can you install your own copy of Linux on an Android device? Only if the manufacturer was kind enough to leave your bootloader unlocked. Can you install your own copy of Linux on a "Designed for Windows 8" device? Yes, as long as you get it signed first.
Open questions:
Will you be able to buy Windows 8 for ARM on a tablet that doesn't have the "Designed for Windows 8" logo certification? If so, then I imagine there will be a lot of vendors willing to forego the logo certification and advertise the tablet as "Linux-compatible". Of course, in that case, I would hope they would advertise that they passed all other "Designed for Windows 8" logo requirements. On the other hand, if Windows 8 for ARM is restricted to OEMs selling properly-certified tablets, OEMs will probably be less likely to sell Linux-compatible variants.
On what terms will 3rd parties be able to sign their operating systems? There will definitely be ways to do it, but it won't be free. Getting the OS signed will probably have a fee, and nobody will want to have an OS signed in their name unless the OS is a "closed system". In other words, I would be very nervous about getting a standard GRUB binary signed in my name, because anybody could then take that GRUB binary and use it as part of a rootkit, and it is not beyond the realm of possibility that I might be held liable for damages done by that rootkit. Instead, I would (at the very least) want to modify GRUB so that it shows a splash screen saying "Warning: this version of GRUB can load unsigned operating systems!". Or if the lawyers have their way, I would probably make my GRUB only load signed kernels so that I can pass the blame to whoever signed the kernel. Anybody signing a kernel will probably want to have the same attitude towards unsigned kernel drivers (and probably even unsigned user-mode drivers, since they usually have special capabilities and extra potential for causing mayhem).
How interested will people be in jailbreaking these devices? So far, the best tablets (the ones on which people want to install their custom builds of Linux) are NOT the "Designed for Windows 8" tablets. Will this change in the future? Microsoft's policy only matters if "Designed for Windows 8" tablets become the best tablets on the market. So far that is not the case. If this does wind up being our future, it is at least several years away. What will the tablet market look like then? Will "Designed for Windows 8" tablets really be the only game in town for your next Linux tablet, or will there be other options?
Will you really want to put your own build of Linux on these tablets? I mean, I love tinkering with my desktop and laptop computers as much as the next guy, but phones and tablets are not general-purpose computers -- they're appliances.
Will the major distro providers (Ubuntu, Debian, Red Hat, FreeBSD) step up to the plate and release signed versions of their distros? Will businesses see enough need for custom operating systems to build and sign a Linux image for internal use?
How does code signing play with various open-source licenses? Is it ok to sign a GPLv2 program? What about GPLv3?
The problem is that by having something signed in your name, you are sort of attesting that the code won't do any bad stuff, directly or indirectly. If you get a GRUB bootloader signed and then somebody uses your GRUB as part of a rootkit, your name is going to be on the rootkit. (Not sure about the actual laws, but there is potential for liability here. Do you have enough lawyers to risk it?)
One way to avoid taking the blame for unfortunate events is to pass the blame to someone else. In the case of code signing, that means a bootloader will only load a kernel if the kernel is signed. That means that if somebody uses the kernel in a rootkit, it isn't the bootloader's problem anymore -- the blame falls on whoever signed the kernel.
Taking it one step more, the kernel can avoid blame by ensuring that it only loads signed drivers. As long as all kernel-mode code is signed, the operating system can make certain assumptions about the world. It might still be running malware, but it's always user-mode malware, never a rootkit or a kernel-mode problem. Keyloggers can only work via approved and documented operating system APIs, etc.
Depending on how secure you want the system to be, you might even extend this "only load signed code" thing all the way into user mode. But that's optional, since the operating system already has a pretty good security layer in place for user mode code.
Probably not. Any OS can boot on a "Designed for Windows 8" ARM device as long as the OS gets itself signed. The device will boot non-Microsoft operating systems just fine as long as they're signed. The only problem is that getting a certificate is not free (probably around $500/year is my guess for what it would cost to be able to sign your own kernel).
The secure mode doesn't "only boot Windows". Instead, it is "only boot signed". There will probably be some Linux (or BSD) distro that goes and pays to get itself signed, and then you can install that distro on your "Designed for Windows 8" ARM device. If the distro includes VirtualBox's kernel-mode driver in the set of drivers that get signed, they you'll be able to use VirtualBox on the device as well. You'll no longer be able to compile your own kernel and kernel modules unless you pay to have them signed.
I agree that this is an overblown issue. However, your understanding is incorrect here. The OS being installed has to be signed with a key that is trusted by the device's UEFI, and the set of trusted keys is hard-coded when the device is manufactured. Microsoft's requirements specifically say that you must not be able to add new trusted keys after the device has been manufactured. I don't know what Microsoft's requirements are for what keys must be included or excluded from the set of trusted keys (I suspect that the "Microsoft Windows Hardware Compatibility" certificate will be trusted; I don't know whether Verisign or other 3rd parties will be allowed to be trusted), but looking at previous similar situations it is almost certain that there will be a way for a 3rd party to get an OS signed if they're willing to pay $500 for a certificate.
So corporations would probably be able to produce a corporate-branded edition of Linux (including signed bootloader, kernel, and kernel modules), either for internal use or to be shared with the world. Non-profit organizations that produce operating systems (FreeBSD and Linux) would have to release signed versions. End users would no longer be able to compile their own kernels or kernel modules if they want to have them run on "Designed for Windows 8" ARM hardware -- they would have to get the kernel and the kernel modules from a certified source. OR they could buy ARM hardware that isn't "Designed for Windows 8" and do whatever they want.
Yeah, the real reason was that the OEM couldn't be bothered to add Linux as an option because it increases production and support costs far more than the cost of a Windows license, while increasing your potential market by 0.01%. I read up on some manufacturers who tried providing Linux options. Generally they discovered that they got more accidental buyers than intentional ones, so offering the Linux option is terribly expensive for them -- they have to add a completely different disk image for the Linux version, they have to add a (potentially confusing) menu option to their order forms, they have to train support staff, the Linux version would tend to produce far more support calls and far more returns, etc., meaning that after all costs have been accounted for, the Linux version costs more for the OEM to produce than the Windows version. (This is for consumer-oriented products; it's usually a different story for server-oriented products.) The "Windows Tax" for most consumer machines is around $20, and even one additional support call can make those "savings" meaningless to the OEM.
Yes, this situation happens to play into Microsoft's hands, but it isn't Microsoft's fault, and there isn't any easy solution. If you can figure out a way for Dell to offer a Linux option for their consumer products that doesn't cost them anything in terms of manufacturing, advertising, training, or support, please share it with them. I'm sure they would be happy to talk. Until then, just buy the PC with the cheapest version of Windows on it (usually Home Basic) and format it as soon as you get it. Maybe try to get your $20 refunded if you really want to stick it to Microsoft on the principle of the thing.
Vista and later enable multiple apps to share use of the GPU (desktop composition). In order to make this work, they have to make GDI work on top of an extra layer of abstraction. With a well-written Vista-compatible video driver, this extra layer of abstraction has little to no performance penalty. However, with the XP-compatible video driver (works on Vista but has limitations), this abstraction has a significant performance penalty which is what you are seeing.
Many GPU manufacturers never released Vista-compatible drivers for their XP-compatible hardware. Instead, you have to run Vista or 7 with XP-compatible drivers and live with the issues.
One workaround is to disable Aero glass (desktop composition). Once that is done, the extra layer of abstraction is no longer needed and your GDI apps will work at regular speed again.
The other workaround is to upgrade to video hardware with a Vista-compatible driver.
Note that Windows 8 will remove support for the XP-compatible drivers.
This is also the case for essentially all "single-core" smartphones. The number of "cores" advertised is the number of full-speed general-purpose CPU cores visible to the applications running on the system-on-chip. There is almost always a smaller slower "modem processor" (often called the DSP) that is a slower ARM core (usually 600 MHz or so) that can handle cell phone processing, MP3 playback, and other non-interactive tasks. If the screen is off, a good smartphone OS should only have the modem processor active, which is how it gets any decent battery life.
Doesn't work. (I tried this a while back.) It turns out that the problem is that most SD card readers and/or their drivers don't support the necessary control of the SD card, so it doesn't matter what application you use -- the SD card can't be unlocked by most existing SD card readers.
Actually, there is no problem. It works fine if you replace it with a like chip (though you'll have to reset the phone since the like chip won't have the data from the original chip). The problem comes from two issues: 1) people replace it with non-like chips and whine that it doesn't work, and 2) people replace it and whine that the chip that was originally in there doesn't work in other devices.
As long as you replace it with a good chip, the phone will work fine. Currently, there is only one chip that is known to be good, but I'm sure that will change with time.
No, the lock/unlock protocol for SD cards is public. Nothing particularly special here, just rarely used. That said, a lot of SD card readers don't support the lock/unlock protocol. A locked card completely confuses most SD card readers, which is why the card doesn't even show up in the OS if it has been locked.
Windows Phone locks the SD card. The SD standard includes an ERASE command that would restore a locked SD card to its original unlocked status. However, most SD card readers don't support sending the ERASE command to the card. So while the SD standard allows for fixing the locked cards, in practice it's pretty hard to do so.
No, that won't work. The disk won't even be recognized if it is locked. The disk can't be selected until it has been recognized as a valid disk. You have to tell the SD card to unlock or erase itself before it will be recognized as a disk, and Windows doesn't currently support the necessary low-level unlock and erase commands.
SD card passwords can also be removed via the ERASE command. The card will then be usable in other devices, and you don't need to know the card's password to perform an ERASE. (Unfortunately I don't know of any commonly-available tool that will perform an ERASE on an SD card. Formatting and repartitioning are not the same thing, and the erase has to happen before you can format or partition.)
1. The "modification" mentioned is that Windows Phone uses the "LOCK" command of the SD card, which sets a password on the card. This is not commonly used, but it is part of the SD card standard. The S in "SD" stands for "Secure", and the "LOCK" command is one of the security features. It is possible to unlock the card via an UNLOCK command (requires the password) or via the ERASE command (does not require the password). Unfortunately, tools that support the LOCK, UNLOCK, and ERASE commands are essentially non-existent on Windows and (as far as I know) Linux.
2. The "special" card required is really just "fast" (can sustain a reasonable number of reads/writes per second) and "reliable" (properly implements the SD card spec and doesn't glitch out too often). The SD card's "class" doesn't matter here, as the class essentially measures how quickly an SD card can carry out a single large read/write operation, while phone performance depends more on how quickly the card can carry out a large number of small read/write operations. Microsoft tested a bunch of SD cards from a bunch of different vendors and found exactly one that met the minimum reliability and performance requirements. This is now the "approved" SD card. It is a class 2 card, which means it isn't particularly great at saving big JPGs, but it had much better random I/O scores than anything else that was tested. Microsoft doesn't sell this card and as far as I know has no financial interest in the sale of the card. Any card that meets the reliability and speed requirements will work just fine in the phone -- the phone isn't programmed to look for anything special in the SD card.
3. The confusion here comes from the fact that the SD slot is supported in a Windows Phone as a way for the retailer of the phone to easily upgrade the storage without involving a soldering iron, not as a way to share files between the phone and other systems. Selling a Windows Phone with an SD slot is like selling a computer with an unused SATA RAID port -- the user can add storage without going back to the manufacturer, but most users aren't expected to add or remove their computer's hard drive on a daily basis.
You've over-simplified the problem and created a false dichotomy. There are many solutions that are more secure than plain-text. It's not a binary decision. You are correct in that you can't get perfect security, but that doesn't mean you can't do better than plain-text. Perfect is the enemy of good.
First, while you cannot achieve true security through obfuscation, you can certainly improve your odds. If I steal a computer and scan cookies and documents looking for passwords, I'm more likely to find and use passwords stored in plaintext than I am to find passwords stored with some kind of reversible encryption. Sure, anybody who knows the details of my app will be able to get the passwords, but that doesn't mean I have to make it obvious and advertise the password data -- make it hard for them, and you'll probably stop 99% of the attacks.
Second, there are often operating system features for storing secure data. The data can be encrypted using the user's password, which is stored in kernel memory on the running system, but is not directly stored on the hard disk (the hard disk stores a hash, not the password itself). Your application can ask the OS to store a secret value, and later you can ask for that value back again. The OS will only be able to give you back the original value if the user is logged on with a correct password. (The OS handles re-encrypting the necessary keys each time the user's password changes.) In Windows, you use the CryptProtectData function. I'm not as familiar with other OS APIs, but I'm sure there are similar APIs on other systems. Not available in restricted scenarios (hard to do this from JavaScript running in the browser), but you should take advantage of the facility if you can.
Finally, if you own both ends of the system (client and server), you can provide challenge/response security that can be pretty strong by using hashes and public/private keys. This is harder, but you can get good security this way. Even in JavaScript.
Part of the security for an application can be attributed to the underlying platfom. It is very difficult to write a secure application on a operating system that doesn't require a user to log-on to access all files on the system. On such a system, anybody who can access a terminal can compromise any unencrypted data from any application, and the application developer must work that much harder to secure the data. On the other hand, on an operating system that has log-in and protects files from access by unauthorized users, an application can store per-user sensitive data in a per-user folder and the data is secure from unauthenticated access.
Of course, physical access trumps log-on access controls (if you can steal the hard drive or get the system to boot into an environment that you control, you can bypass the filesystem security). OS features such as whole-disk encryption can help in this scenario, once again making the application developer's job easier by providing a secure-by-default platform.
For Desktop PCs, such encryption is still somewhat optional. If you can provide physical security (lock your house), you don't need data security (encrypt your hard drive) quite as much.
With a mobile device such as a laptop or smartphone, this kind of encryption is very important. If the data on a smartphone can be accessed without logging in, then somebody just needs to steal your phone to access your data. Phones are stolen all the time, so plaintext data on a smartphone is a serious security problem.
Some smartphones have a nifty feature that allows you to treat the phone as a mass storage device. Unfortunately, this feature can be a serious liability if it allows somebody to access data on the phone without going through the OS's filesystem security. Phones that have this feature are more usable, but developers writing apps for this kind of phone need to do more work to ensure that their applications are secure. Applications on phones that don't allow such access are secure by default.
Some phones allow you to store data on an SD card, then remove the card and insert it into another system to read the data. Again, this is a very useful feature, but it can also be a serious security hole if there is any sensitive data on that SD card. Once again, if the phone has this feature, the application developer needs to take additional precautions to ensure that no sensitive information is stored on the SD card.
Some phones encrypt all data stored on the SD card. This renders the SD card useless as removable storage, but it means that sensitive data stored on the SD card is less likely to be revealed if the phone is stolen.
Bottom line is that the design of the smartphone platform (including the platform's limitations) have a lot to do with the security of the applications. I have no trouble believing that the same dumb developer might write the same app for two different platforms and the resulting app might be totally secure on one platform and totally insecure on the other, simply because of differences in the operating system design.
There are several different limitations in effect. Each of them may or may not apply, depending on specific circumstances.
- Number of address pins on the CPU or socket: 8088 had 20, limiting it to 1MB; 80386 had 24, limiting it to 16 MB; Pentium had 32, limiting it to 4 GB; Pentium Pro had 36, limiting it to 64 GB;...
- Number of address lines on the motherboard: many motherboards (especially laptops) only connect the low 32 address lines, limiting them to 4 GB.
- Chipset memory support: chipsets may limit the size and quantity the memory module, i.e. max 4 memory modules, cannot support modules larger than 512MB.
- Device requirements: Memory-mapped devices (like video cards) usually need to be mapped to an address below some limit. On 8088, the range from 640k-1MB was reserved and couldn't be used for RAM. In PCI, the mapping is more flexible, so address ranges are only reserved if there is actually a device that needs the range. Instead of reserving the range, the device "shadows" the memory at that range (if any). This is usually in the 3GB to 4GB range.
- Chipset remapping support: Memory that is "shadowed" cannot be accessed at its "natural" address. If the motherboard does not support remapping, shadowed memory is inaccessible and wasted. If the motherboard does support remapping, shadowed memory can be remapped to some other address, usually somewhere above 4GB.
- OS PAE support: To access memory above the 4GB limit from a 32-bit CPU, the OS must put the CPU into PAE mode. All modern OSes support this. 32-bit Windows will run in PAE mode if you've enabled "Data Execution Prevention", whether or not you have more than 4GB of memory. (This is not an issue for a 64-bit operating system -- there is no need for PAE if the chip is running in 64-bit mode.)
- Driver support: DMA transfers to PCI devices only work with addresses below 4GB. Drivers must be designed to special-case any requests to transfer data to/from addresses above 4GB (usually done by allocating a temporary buffer below 4GB and copying the data to the temporary buffer). Systems that use drivers that aren't high-address-aware must avoid using physical addresses above 4GB.
- Application support: A 32-bit application can directly access no more than 4GB of address space, some of which will be reserved for use by the operating system. There are workarounds that enable indirect access to more RAM, or the application can be recompiled as a 64-bit application.
- OS edition limitation: Commercial OSes often artificially limit RAM usage for various reasons including edition differentiation and driver compatibility.
The 4GB limitation on consumer editions of Windows is due to driver compatibility issues. (Note that this is a limit on physical address size, not a limit on the amount of memory.) Microsoft originally placed a completely artificial 8GB limit on the amount of memory available to consumer editions of XP (for edition differentiation reasons only). However, driver problems appeared on systems that used addresses above the 4GB limit, so Microsoft changed this to a 4GB address limit (not a 4GB memory limit!) to improve stability on consumer systems (and reduce support calls). This limit is not present on server systems, since Microsoft assumes that server administrators will use higher-quality hardware and/or drivers. Cheaper editions of the server OS do have artificial memory limits (i.e. 16GB). The most expensive edition of the 32-bit server OS has no artificial limit and can access the full 64GB exposed by 36-bit PAE.
64-bit systems also have limits. As far as I know, the 192GB limit is entirely artificial - if you need more memory than that, Microsoft probably figures you should buy one of the server editions of Windows. The 1TB limit on the server edition is probably based on test limits - Microsoft doesn't want to support something it hasn't tested. However, even with a 64-bit edition of Windows, you may still be limited (i.e. my old laptop only had 32 address li
This is called "fraud". Look it up. It's been around for a long time, a lot longer than HTTP. There are standard business practices for dealing with it. Not all of them are technical. This system's technical defenses are probably sufficient to raise an alarm (delayed by a few weeks as the results are collated), and it will produce a pretty good paper trail leading to the owner of the Bing account. Some of the systems take into account minor details such as the existence of accountants, a police force, a paper trail, and a legal system. Obviously some stronger technical measures might have made it a bit more difficult to pull off this partucular fraud, or maybe it might have even stopped it, but the non-technical measures will also work just fine if they are called into play.
Whether or not the door is obviously guarded, it's still illegal to steal stuff from a store. The fact that the door was not protected with the latest and greatest in RFID theft detection systems doesn't change the fact that what you are doing is illegal. And perhaps the tracking process is slower than what you see in movies, people still get tracked down and arrested, days or weeks after the event. Moving from the streets onto the Internet doesn't really change the rules much (except that your case will probably wind up with Federal jurisdiction).
In this case, the poor "hacker" (I wish him/her luck!) appears to have done the following: 1. Used a specially formatted HTTP request to get a small fabricated purchase to show up as credited to his/her Bing account. 2. Noticed that the cash back did show up with no problem as "available for withdrawal". 3. Tried again with a much larger purchase. Again the purchase shows up in his account. 4. Hacker is hoping that the amount will soon become available for withdrawal.
On the other side of the world, the accounting systems for Microsoft and the associated merchant have likely compared invoices and noticed the discrepancies. The small ones got noted, but they were thrown out as "somebody is playing with the system, but it's not worth dealing with it". But this month, when going over the books, they're going to find a nice big 100,000 item that doesn't match up with any purchase recorded on the store's official records. However, they do have the account number of the buyer that should be getting the cash back. I'm not sure what typically happens at this point, but it probably involves cancelling dinner for the wolf pack so that by the time they're ready to send out the posse, the wolves are hungry.
In this case, Microsoft has apparently (I haven't looked into this) provided an API by which a store can report a sale and attribute the sale to a particular Bing account. The API has varying levels of security, depending on how much effort the store wants to put into preventing fake transactions from entering the system. Low effort might be fine and takes less time to set up, but it's easier to attack and that means more work to do when reconciling the accounts. Just like many other mechanisms for quickly distributing non-critical information between merchants, this isn't meant to be the authoritative information transmission system, just a way for people to keep status on accounts in between the regularly-scheduled account reconciliations. This way Bing can update your account balance within seconds of the purchase. Of course, the payback won't happen until they've gone back and checked Microsoft's records against the merchant's records and pulled out any differences. The differences go to the auditor and possibly to the police or FBI.
Could we maybe just think for a second before acting like jerks? Being a jerk means everybody suffers. I mean, just because I see a way to deface somebody's website doesn't mean I am obligated to do so. I walk by 100 cars a day, and I could easily spray shaving cream all over them and not get caught. But if everybody did that, quality of life would go down for everybody. Same thing on the internet.
Slashdot Mirror
The Register article has a bit more information. This isn't really a vulnerability. It's definitely not "remote code execution". It works like this:
- Microsoft provides a tool called AppLocker that can be used to limit the programs that can be run on a system.
- The AppLocker tool is not intended as a tight "security boundary". Instead, it is a way to implement company policies like "no playing games at work", or to help with software licensing, i.e. "the company system image has a copy of Photoshop, but you aren't in the Design department, so you aren't licensed to run it", and perhaps to reduce attack surface area.
- The Microsoft-provided sample AppLocker configuration (intended to show the syntax for AppLocker rules) happens to have a sample rule that whitelists all programs under C:\windows. This is not a "recommended" rule -- it's a "sample" rule.
- If you leave this rule in, there are a large number of ways to escape the sandbox.
- A researcher found another one. Yay, I guess?
The new one is interesting because I wouldn't have considered regsvr32 to be a command that allows for running of arbitrary other commands. On the other hand, it shouldn't belong in a production whitelist in the first place, so being able to use it to escape the sandbox isn't particularly interesting.
Whether Kinect is a failure depends on exactly how you define success.
-- Controlling the games we're used to playing on the xbox? FAIL.
-- Getting good reviews from people who review games on our favorite gaming websites? FAIL.
-- Selling a lot of units? WIN.
-- Has some games that some consumers really like? WIN.
-- Good as an input mechanism for some interesting non-traditional uses? WIN.
-- The future of gaming? FAIL.
-- The future of computer-human interaction? PROBABLY.
As an additional note, the first version isn't terribly awesome, but inevitably it'll get better in the future.
One addition is that it is more likely nowadays than ever before for a really messed-up person to survive long enough to provide a contribution to society. Once upon a time, people that saw the world differently were more likely to be abandoned by parents, killed by peers, or starve to death as beggars. Nowadays, geeks are more likely than ever before to find a few people that understand them and are willing to give them a job, turning their unique attributes to good ends. Where geeks used to be lucky to avoid being executed for heresy, nowadays they can make a good living and sometimes even become rich and famous.
A few relevant thoughts come to mind.
First, all greatness depends on insanity. The sane come up with an interesting idea, start thinking about it, see a lot of hard work and little chance for reward, and give it up before it gets very far. The insane pursue the idea to the bitter end. 99% (or more) of the time, "the bitter end" means self-destruction and disappointment. 1% (or less) of the time, the result is something truly great that pushes science/art/civilization/whatever forward another tiny step. Sometimes it is both -- many important innovations were only seen as good long after the innovator had been punished for the crime of innovating.
Second, similar but not quite the same as the first, is a saying that I'm probably going to misquote. "The rational man adapts himself to fit into his surroundings. The irrational man persists in trying to adapt his surroundings to fit himself. Therefore, all progress depends on the irrational man." Unmentioned here is that 99.9% of the time, the irrational man will fail and will be harmed due to his efforts while 99.9% of the time the rational man will thrive or at least survive.
After the testing you will be baked and then there will be cake.
If you pay full price for Windows, you get full rights. Microsoft is willing to give you a discount if you accept more limited terms. Most people are ok with the limited terms and are therefore very happy to accept the discount. If you don't like those terms, you have the option of not buying the product.
I think it is a little bit interesting that Microsoft has divided the market between x86 and ARM differently than it has divided the market between x86 and amd64. In theory, you could have a general-purpose ARM-based server, desktop, or notebook. And in theory, you could have an x86-based tablet. So in theory, Microsoft should be adding "Windows 8 tablet edition for x86", "Windows 8 tablet edition for ARM", "Windows 8 Professional for ARM", and "Windows 8 Server for ARM" to its lineup. However, theory never quite matches up with reality.
In reality, of the editions listed above, only "Windows 8 tablet edition for ARM" is likely to have any market at all in the next 2 years, so Microsoft is probably not going to offer the other 3 editions. When the market changes (e.g. if ARM servers really take off), Microsoft will add editions as necessary for Windows 9. If Intel takes over the tablet market, there will certainly be a Windows 9 tablet edition for x86. And your guess is as good as mine about which of these editions will require secure boot.
I don't think it is accurate to say that "any ARM device that ships with Windows 8 will never run another operating system unless...". First, it should be changed to "any ARM device with the 'Designed for Windows 8' logo will never run another operating system unless..." since it isn't the presence of Windows 8 that determines the status of secure boot. Second, the "unless..." part is pretty important and should be emphasized. Just as Microsoft will be able to sign Windows, other organizations will be able to sign their own operating systems. And hacking/jailbreaking will always happen. So it is more accurate to say "any ARM device with the 'Designed for Windows 8' logo will have to be jailbroken before it can run any unsigned operating system".
In any case, it seems that Microsoft's rules here are the most open of any tablet manufacturer. Can you install your own copy of Linux on an iPad? No. Can you install your own copy of Linux on an Android device? Only if the manufacturer was kind enough to leave your bootloader unlocked. Can you install your own copy of Linux on a "Designed for Windows 8" device? Yes, as long as you get it signed first.
Open questions:
Will you be able to buy Windows 8 for ARM on a tablet that doesn't have the "Designed for Windows 8" logo certification? If so, then I imagine there will be a lot of vendors willing to forego the logo certification and advertise the tablet as "Linux-compatible". Of course, in that case, I would hope they would advertise that they passed all other "Designed for Windows 8" logo requirements. On the other hand, if Windows 8 for ARM is restricted to OEMs selling properly-certified tablets, OEMs will probably be less likely to sell Linux-compatible variants.
On what terms will 3rd parties be able to sign their operating systems? There will definitely be ways to do it, but it won't be free. Getting the OS signed will probably have a fee, and nobody will want to have an OS signed in their name unless the OS is a "closed system". In other words, I would be very nervous about getting a standard GRUB binary signed in my name, because anybody could then take that GRUB binary and use it as part of a rootkit, and it is not beyond the realm of possibility that I might be held liable for damages done by that rootkit. Instead, I would (at the very least) want to modify GRUB so that it shows a splash screen saying "Warning: this version of GRUB can load unsigned operating systems!". Or if the lawyers have their way, I would probably make my GRUB only load signed kernels so that I can pass the blame to whoever signed the kernel. Anybody signing a kernel will probably want to have the same attitude towards unsigned kernel drivers (and probably even unsigned user-mode drivers, since they usually have special capabilities and extra potential for causing mayhem).
How interested will people be in jailbreaking these devices? So far, the best tablets (the ones on which people want to install their custom builds of Linux) are NOT the "Designed for Windows 8" tablets. Will this change in the future? Microsoft's policy only matters if "Designed for Windows 8" tablets become the best tablets on the market. So far that is not the case. If this does wind up being our future, it is at least several years away. What will the tablet market look like then? Will "Designed for Windows 8" tablets really be the only game in town for your next Linux tablet, or will there be other options?
Will you really want to put your own build of Linux on these tablets? I mean, I love tinkering with my desktop and laptop computers as much as the next guy, but phones and tablets are not general-purpose computers -- they're appliances.
Will the major distro providers (Ubuntu, Debian, Red Hat, FreeBSD) step up to the plate and release signed versions of their distros? Will businesses see enough need for custom operating systems to build and sign a Linux image for internal use?
How does code signing play with various open-source licenses? Is it ok to sign a GPLv2 program? What about GPLv3?
The problem is that by having something signed in your name, you are sort of attesting that the code won't do any bad stuff, directly or indirectly. If you get a GRUB bootloader signed and then somebody uses your GRUB as part of a rootkit, your name is going to be on the rootkit. (Not sure about the actual laws, but there is potential for liability here. Do you have enough lawyers to risk it?)
One way to avoid taking the blame for unfortunate events is to pass the blame to someone else. In the case of code signing, that means a bootloader will only load a kernel if the kernel is signed. That means that if somebody uses the kernel in a rootkit, it isn't the bootloader's problem anymore -- the blame falls on whoever signed the kernel.
Taking it one step more, the kernel can avoid blame by ensuring that it only loads signed drivers. As long as all kernel-mode code is signed, the operating system can make certain assumptions about the world. It might still be running malware, but it's always user-mode malware, never a rootkit or a kernel-mode problem. Keyloggers can only work via approved and documented operating system APIs, etc.
Depending on how secure you want the system to be, you might even extend this "only load signed code" thing all the way into user mode. But that's optional, since the operating system already has a pretty good security layer in place for user mode code.
Probably not. Any OS can boot on a "Designed for Windows 8" ARM device as long as the OS gets itself signed. The device will boot non-Microsoft operating systems just fine as long as they're signed. The only problem is that getting a certificate is not free (probably around $500/year is my guess for what it would cost to be able to sign your own kernel).
The secure mode doesn't "only boot Windows". Instead, it is "only boot signed". There will probably be some Linux (or BSD) distro that goes and pays to get itself signed, and then you can install that distro on your "Designed for Windows 8" ARM device. If the distro includes VirtualBox's kernel-mode driver in the set of drivers that get signed, they you'll be able to use VirtualBox on the device as well. You'll no longer be able to compile your own kernel and kernel modules unless you pay to have them signed.
I agree that this is an overblown issue. However, your understanding is incorrect here. The OS being installed has to be signed with a key that is trusted by the device's UEFI, and the set of trusted keys is hard-coded when the device is manufactured. Microsoft's requirements specifically say that you must not be able to add new trusted keys after the device has been manufactured. I don't know what Microsoft's requirements are for what keys must be included or excluded from the set of trusted keys (I suspect that the "Microsoft Windows Hardware Compatibility" certificate will be trusted; I don't know whether Verisign or other 3rd parties will be allowed to be trusted), but looking at previous similar situations it is almost certain that there will be a way for a 3rd party to get an OS signed if they're willing to pay $500 for a certificate.
So corporations would probably be able to produce a corporate-branded edition of Linux (including signed bootloader, kernel, and kernel modules), either for internal use or to be shared with the world. Non-profit organizations that produce operating systems (FreeBSD and Linux) would have to release signed versions. End users would no longer be able to compile their own kernels or kernel modules if they want to have them run on "Designed for Windows 8" ARM hardware -- they would have to get the kernel and the kernel modules from a certified source. OR they could buy ARM hardware that isn't "Designed for Windows 8" and do whatever they want.
Yeah, the real reason was that the OEM couldn't be bothered to add Linux as an option because it increases production and support costs far more than the cost of a Windows license, while increasing your potential market by 0.01%. I read up on some manufacturers who tried providing Linux options. Generally they discovered that they got more accidental buyers than intentional ones, so offering the Linux option is terribly expensive for them -- they have to add a completely different disk image for the Linux version, they have to add a (potentially confusing) menu option to their order forms, they have to train support staff, the Linux version would tend to produce far more support calls and far more returns, etc., meaning that after all costs have been accounted for, the Linux version costs more for the OEM to produce than the Windows version. (This is for consumer-oriented products; it's usually a different story for server-oriented products.) The "Windows Tax" for most consumer machines is around $20, and even one additional support call can make those "savings" meaningless to the OEM.
Yes, this situation happens to play into Microsoft's hands, but it isn't Microsoft's fault, and there isn't any easy solution. If you can figure out a way for Dell to offer a Linux option for their consumer products that doesn't cost them anything in terms of manufacturing, advertising, training, or support, please share it with them. I'm sure they would be happy to talk. Until then, just buy the PC with the cheapest version of Windows on it (usually Home Basic) and format it as soon as you get it. Maybe try to get your $20 refunded if you really want to stick it to Microsoft on the principle of the thing.
Vista and later enable multiple apps to share use of the GPU (desktop composition). In order to make this work, they have to make GDI work on top of an extra layer of abstraction. With a well-written Vista-compatible video driver, this extra layer of abstraction has little to no performance penalty. However, with the XP-compatible video driver (works on Vista but has limitations), this abstraction has a significant performance penalty which is what you are seeing.
Many GPU manufacturers never released Vista-compatible drivers for their XP-compatible hardware. Instead, you have to run Vista or 7 with XP-compatible drivers and live with the issues.
One workaround is to disable Aero glass (desktop composition). Once that is done, the extra layer of abstraction is no longer needed and your GDI apps will work at regular speed again.
The other workaround is to upgrade to video hardware with a Vista-compatible driver.
Note that Windows 8 will remove support for the XP-compatible drivers.
This is also the case for essentially all "single-core" smartphones. The number of "cores" advertised is the number of full-speed general-purpose CPU cores visible to the applications running on the system-on-chip. There is almost always a smaller slower "modem processor" (often called the DSP) that is a slower ARM core (usually 600 MHz or so) that can handle cell phone processing, MP3 playback, and other non-interactive tasks. If the screen is off, a good smartphone OS should only have the modem processor active, which is how it gets any decent battery life.
Doesn't work. (I tried this a while back.) It turns out that the problem is that most SD card readers and/or their drivers don't support the necessary control of the SD card, so it doesn't matter what application you use -- the SD card can't be unlocked by most existing SD card readers.
Actually, there is no problem. It works fine if you replace it with a like chip (though you'll have to reset the phone since the like chip won't have the data from the original chip). The problem comes from two issues: 1) people replace it with non-like chips and whine that it doesn't work, and 2) people replace it and whine that the chip that was originally in there doesn't work in other devices.
As long as you replace it with a good chip, the phone will work fine. Currently, there is only one chip that is known to be good, but I'm sure that will change with time.
No, the lock/unlock protocol for SD cards is public. Nothing particularly special here, just rarely used. That said, a lot of SD card readers don't support the lock/unlock protocol. A locked card completely confuses most SD card readers, which is why the card doesn't even show up in the OS if it has been locked.
Windows Phone locks the SD card. The SD standard includes an ERASE command that would restore a locked SD card to its original unlocked status. However, most SD card readers don't support sending the ERASE command to the card. So while the SD standard allows for fixing the locked cards, in practice it's pretty hard to do so.
No, that won't work. The disk won't even be recognized if it is locked. The disk can't be selected until it has been recognized as a valid disk. You have to tell the SD card to unlock or erase itself before it will be recognized as a disk, and Windows doesn't currently support the necessary low-level unlock and erase commands.
SD card passwords can also be removed via the ERASE command. The card will then be usable in other devices, and you don't need to know the card's password to perform an ERASE. (Unfortunately I don't know of any commonly-available tool that will perform an ERASE on an SD card. Formatting and repartitioning are not the same thing, and the erase has to happen before you can format or partition.)
1. The "modification" mentioned is that Windows Phone uses the "LOCK" command of the SD card, which sets a password on the card. This is not commonly used, but it is part of the SD card standard. The S in "SD" stands for "Secure", and the "LOCK" command is one of the security features. It is possible to unlock the card via an UNLOCK command (requires the password) or via the ERASE command (does not require the password). Unfortunately, tools that support the LOCK, UNLOCK, and ERASE commands are essentially non-existent on Windows and (as far as I know) Linux.
2. The "special" card required is really just "fast" (can sustain a reasonable number of reads/writes per second) and "reliable" (properly implements the SD card spec and doesn't glitch out too often). The SD card's "class" doesn't matter here, as the class essentially measures how quickly an SD card can carry out a single large read/write operation, while phone performance depends more on how quickly the card can carry out a large number of small read/write operations. Microsoft tested a bunch of SD cards from a bunch of different vendors and found exactly one that met the minimum reliability and performance requirements. This is now the "approved" SD card. It is a class 2 card, which means it isn't particularly great at saving big JPGs, but it had much better random I/O scores than anything else that was tested. Microsoft doesn't sell this card and as far as I know has no financial interest in the sale of the card. Any card that meets the reliability and speed requirements will work just fine in the phone -- the phone isn't programmed to look for anything special in the SD card.
3. The confusion here comes from the fact that the SD slot is supported in a Windows Phone as a way for the retailer of the phone to easily upgrade the storage without involving a soldering iron, not as a way to share files between the phone and other systems. Selling a Windows Phone with an SD slot is like selling a computer with an unused SATA RAID port -- the user can add storage without going back to the manufacturer, but most users aren't expected to add or remove their computer's hard drive on a daily basis.
You've over-simplified the problem and created a false dichotomy. There are many solutions that are more secure than plain-text. It's not a binary decision. You are correct in that you can't get perfect security, but that doesn't mean you can't do better than plain-text. Perfect is the enemy of good.
First, while you cannot achieve true security through obfuscation, you can certainly improve your odds. If I steal a computer and scan cookies and documents looking for passwords, I'm more likely to find and use passwords stored in plaintext than I am to find passwords stored with some kind of reversible encryption. Sure, anybody who knows the details of my app will be able to get the passwords, but that doesn't mean I have to make it obvious and advertise the password data -- make it hard for them, and you'll probably stop 99% of the attacks.
Second, there are often operating system features for storing secure data. The data can be encrypted using the user's password, which is stored in kernel memory on the running system, but is not directly stored on the hard disk (the hard disk stores a hash, not the password itself). Your application can ask the OS to store a secret value, and later you can ask for that value back again. The OS will only be able to give you back the original value if the user is logged on with a correct password. (The OS handles re-encrypting the necessary keys each time the user's password changes.) In Windows, you use the CryptProtectData function. I'm not as familiar with other OS APIs, but I'm sure there are similar APIs on other systems. Not available in restricted scenarios (hard to do this from JavaScript running in the browser), but you should take advantage of the facility if you can.
Finally, if you own both ends of the system (client and server), you can provide challenge/response security that can be pretty strong by using hashes and public/private keys. This is harder, but you can get good security this way. Even in JavaScript.
Part of the security for an application can be attributed to the underlying platfom. It is very difficult to write a secure application on a operating system that doesn't require a user to log-on to access all files on the system. On such a system, anybody who can access a terminal can compromise any unencrypted data from any application, and the application developer must work that much harder to secure the data. On the other hand, on an operating system that has log-in and protects files from access by unauthorized users, an application can store per-user sensitive data in a per-user folder and the data is secure from unauthenticated access.
Of course, physical access trumps log-on access controls (if you can steal the hard drive or get the system to boot into an environment that you control, you can bypass the filesystem security). OS features such as whole-disk encryption can help in this scenario, once again making the application developer's job easier by providing a secure-by-default platform.
For Desktop PCs, such encryption is still somewhat optional. If you can provide physical security (lock your house), you don't need data security (encrypt your hard drive) quite as much.
With a mobile device such as a laptop or smartphone, this kind of encryption is very important. If the data on a smartphone can be accessed without logging in, then somebody just needs to steal your phone to access your data. Phones are stolen all the time, so plaintext data on a smartphone is a serious security problem.
Some smartphones have a nifty feature that allows you to treat the phone as a mass storage device. Unfortunately, this feature can be a serious liability if it allows somebody to access data on the phone without going through the OS's filesystem security. Phones that have this feature are more usable, but developers writing apps for this kind of phone need to do more work to ensure that their applications are secure. Applications on phones that don't allow such access are secure by default.
Some phones allow you to store data on an SD card, then remove the card and insert it into another system to read the data. Again, this is a very useful feature, but it can also be a serious security hole if there is any sensitive data on that SD card. Once again, if the phone has this feature, the application developer needs to take additional precautions to ensure that no sensitive information is stored on the SD card.
Some phones encrypt all data stored on the SD card. This renders the SD card useless as removable storage, but it means that sensitive data stored on the SD card is less likely to be revealed if the phone is stolen.
Bottom line is that the design of the smartphone platform (including the platform's limitations) have a lot to do with the security of the applications. I have no trouble believing that the same dumb developer might write the same app for two different platforms and the resulting app might be totally secure on one platform and totally insecure on the other, simply because of differences in the operating system design.
There are several different limitations in effect. Each of them may or may not apply, depending on specific circumstances.
- Number of address pins on the CPU or socket: 8088 had 20, limiting it to 1MB; 80386 had 24, limiting it to 16 MB; Pentium had 32, limiting it to 4 GB; Pentium Pro had 36, limiting it to 64 GB; ...
- Number of address lines on the motherboard: many motherboards (especially laptops) only connect the low 32 address lines, limiting them to 4 GB.
- Chipset memory support: chipsets may limit the size and quantity the memory module, i.e. max 4 memory modules, cannot support modules larger than 512MB.
- Device requirements: Memory-mapped devices (like video cards) usually need to be mapped to an address below some limit. On 8088, the range from 640k-1MB was reserved and couldn't be used for RAM. In PCI, the mapping is more flexible, so address ranges are only reserved if there is actually a device that needs the range. Instead of reserving the range, the device "shadows" the memory at that range (if any). This is usually in the 3GB to 4GB range.
- Chipset remapping support: Memory that is "shadowed" cannot be accessed at its "natural" address. If the motherboard does not support remapping, shadowed memory is inaccessible and wasted. If the motherboard does support remapping, shadowed memory can be remapped to some other address, usually somewhere above 4GB.
- OS PAE support: To access memory above the 4GB limit from a 32-bit CPU, the OS must put the CPU into PAE mode. All modern OSes support this. 32-bit Windows will run in PAE mode if you've enabled "Data Execution Prevention", whether or not you have more than 4GB of memory. (This is not an issue for a 64-bit operating system -- there is no need for PAE if the chip is running in 64-bit mode.)
- Driver support: DMA transfers to PCI devices only work with addresses below 4GB. Drivers must be designed to special-case any requests to transfer data to/from addresses above 4GB (usually done by allocating a temporary buffer below 4GB and copying the data to the temporary buffer). Systems that use drivers that aren't high-address-aware must avoid using physical addresses above 4GB.
- Application support: A 32-bit application can directly access no more than 4GB of address space, some of which will be reserved for use by the operating system. There are workarounds that enable indirect access to more RAM, or the application can be recompiled as a 64-bit application.
- OS edition limitation: Commercial OSes often artificially limit RAM usage for various reasons including edition differentiation and driver compatibility.
The 4GB limitation on consumer editions of Windows is due to driver compatibility issues. (Note that this is a limit on physical address size, not a limit on the amount of memory.) Microsoft originally placed a completely artificial 8GB limit on the amount of memory available to consumer editions of XP (for edition differentiation reasons only). However, driver problems appeared on systems that used addresses above the 4GB limit, so Microsoft changed this to a 4GB address limit (not a 4GB memory limit!) to improve stability on consumer systems (and reduce support calls). This limit is not present on server systems, since Microsoft assumes that server administrators will use higher-quality hardware and/or drivers. Cheaper editions of the server OS do have artificial memory limits (i.e. 16GB). The most expensive edition of the 32-bit server OS has no artificial limit and can access the full 64GB exposed by 36-bit PAE.
64-bit systems also have limits. As far as I know, the 192GB limit is entirely artificial - if you need more memory than that, Microsoft probably figures you should buy one of the server editions of Windows. The 1TB limit on the server edition is probably based on test limits - Microsoft doesn't want to support something it hasn't tested. However, even with a 64-bit edition of Windows, you may still be limited (i.e. my old laptop only had 32 address li
This is called "fraud". Look it up. It's been around for a long time, a lot longer than HTTP. There are standard business practices for dealing with it. Not all of them are technical. This system's technical defenses are probably sufficient to raise an alarm (delayed by a few weeks as the results are collated), and it will produce a pretty good paper trail leading to the owner of the Bing account. Some of the systems take into account minor details such as the existence of accountants, a police force, a paper trail, and a legal system. Obviously some stronger technical measures might have made it a bit more difficult to pull off this partucular fraud, or maybe it might have even stopped it, but the non-technical measures will also work just fine if they are called into play.
Whether or not the door is obviously guarded, it's still illegal to steal stuff from a store. The fact that the door was not protected with the latest and greatest in RFID theft detection systems doesn't change the fact that what you are doing is illegal. And perhaps the tracking process is slower than what you see in movies, people still get tracked down and arrested, days or weeks after the event. Moving from the streets onto the Internet doesn't really change the rules much (except that your case will probably wind up with Federal jurisdiction).
In this case, the poor "hacker" (I wish him/her luck!) appears to have done the following:
1. Used a specially formatted HTTP request to get a small fabricated purchase to show up as credited to his/her Bing account.
2. Noticed that the cash back did show up with no problem as "available for withdrawal".
3. Tried again with a much larger purchase. Again the purchase shows up in his account.
4. Hacker is hoping that the amount will soon become available for withdrawal.
On the other side of the world, the accounting systems for Microsoft and the associated merchant have likely compared invoices and noticed the discrepancies. The small ones got noted, but they were thrown out as "somebody is playing with the system, but it's not worth dealing with it". But this month, when going over the books, they're going to find a nice big 100,000 item that doesn't match up with any purchase recorded on the store's official records. However, they do have the account number of the buyer that should be getting the cash back. I'm not sure what typically happens at this point, but it probably involves cancelling dinner for the wolf pack so that by the time they're ready to send out the posse, the wolves are hungry.
In this case, Microsoft has apparently (I haven't looked into this) provided an API by which a store can report a sale and attribute the sale to a particular Bing account. The API has varying levels of security, depending on how much effort the store wants to put into preventing fake transactions from entering the system. Low effort might be fine and takes less time to set up, but it's easier to attack and that means more work to do when reconciling the accounts. Just like many other mechanisms for quickly distributing non-critical information between merchants, this isn't meant to be the authoritative information transmission system, just a way for people to keep status on accounts in between the regularly-scheduled account reconciliations. This way Bing can update your account balance within seconds of the purchase. Of course, the payback won't happen until they've gone back and checked Microsoft's records against the merchant's records and pulled out any differences. The differences go to the auditor and possibly to the police or FBI.
Could we maybe just think for a second before acting like jerks? Being a jerk means everybody suffers. I mean, just because I see a way to deface somebody's website doesn't mean I am obligated to do so. I walk by 100 cars a day, and I could easily spray shaving cream all over them and not get caught. But if everybody did that, quality of life would go down for everybody. Same thing on the internet.
I hate this attitude out there th