You don't, and you never have. What you might have needed was a license to make a copy of software (a "game save") or something like that. You might have included copyrighted code in the patch you uploaded into the system. Again, that would need a license. But to mod your hardware? No license is, or ever has been, necesary.
Actaully, Moglin, in particular, has made comments about how Linux would be automatically relicencsed and the like. The FSF is trying very hard to enforce its will on Linus, against his will.
Me, I think that shows a really interesting use of the word "freedom". "All software is free, but Gnu's is more freer than others", or something like that.
Actually, for a while, the FSF maintained that the output of Bison was, in fact, automatically GPL'ed. I don't know if they still maintain that position, but they certainly did claim that the output of a compiler could be automatically subject to GPL.
I don't understand what you mean by "the claims for foreign markets seem patently false as the 360 [goes]." Which claims are you talking about? The PS2/360 outside the United States? The claims that the 360 has sold as many as it has?
You're changing the subject. Sure, the 360 is doing terribly in Japan. That doesn't speak to whether (a) it's worth producing games for the console or (b) whether Microsoft's sales figure are valid or not. For the first of these, the Japanese market is a write-off for non-Japanese development houses, which covers Microsoft's main producers, so the only question is whether game developers can target the US and Europe, and still make money. As to the second, there's no way to refute it; it's the definition of sales for Microsoft.
Nope. MS does not benefit from the subsequent sale.
You ask "B-b-but, what about third party developers? What about games?" Again, you're looking at the question wrong. The question of how many consoles sell is only tangentially of interest to Microsoft any more. The question that drive third party developers is not "how many consoles will sell to consumers", but "will enough consoles eventually sell to consumers to make it worth developing games," and, as we've already seen, the answer to that is "yes". Between the delays in the PS3 and the number of 360's which have already sold, the console is worth taking a risk on.
If memory serves MSF[T] shipped 200,000 units for 450,000 PS2's. but that's just from bad memory.
Actually, in calendar 2006, the 360 has been running roughly neck-in-neck, and even caught the PS2 once, in April. Not that is matters -- the parent's core point, that the 360 isn't beating a last-gen console, stands.
As far a MS is concerned, those *are* sales. The retailer may or may not actually hand the product off to a customer, but Microsoft doesn't benefit from that subsequent retail transaction.
Sorry, fan-boi, but MS is quoting the relevant figure here, much as you'd like to displarage it.
What the article said is the the Ministry of Defense researchers were able to run malicious code through OO.o without a warning -- by design. That's the equivalent of the IE design flaw in which a control could be loaded w/out user intervention, and then queried to see if it was safe for scripting -- before there was any evidence one way or another. Would you claim thatthe IE flaw wasn't a catastrophic design error?
Actually, if Ars Technica is to be believed, the French Office of Defense has done a comparitive security analysis, and Open Office lost badly. The kinds of bugs the OO.o had were design bugs; these are file handling bugs. If equivalent design bugs existed in Office, they'd be the ones exploited, not the harder to find and exploit data validation bugs.
There was a famous theft in which a large number of antique chairs were stolen from an office in broad daylight during working hours, with the staff present.
The thieves drove up in a moving truck, wearing appropriate clothes, and explained that the chairs were being transferred to a different office. They presented "requisitions" to sign, got signatures, filled the truck, and dorve away.
If you look back at the original NT 3.1 documentation, there's an extensive discussion of how different window messages are handled (it depends on their WM_ value, FWIW.) The fact that any window can be a target for any message is documented there, along with the security consequences of that decision.
Bottom line: shatter is real, but only for incorrectly designed applications.
Actually, no, the Network DDE service had such a window back in 1998. That bug -- which was a real excalation of priviledge defect, found by the author of BackOrifice -- was fixed back then. The original shatter vulnerability was found two years later, and, amusingly, didn't involve any Windows component; rather, it had to do with a third-party virus scanning application.
COM was restructured so that DDE didn't a service-associated window, avoiding the privilege attack.
Actually, it is not a "grave design error". A properly designed service should have no window handlers in the privileged process, and should communicate with any other process through a shared memory interface. The desktop is the security boundary on Windows for window messages, not the window.
Well, actually, the Windows.exe is only 29.2MB, but it requires a mandatory optional 11GB download called "requiredoptionalresources.dll", which is a pure resource DLL.
For Linux, of course, you need to d/l the entire tarball.
Yeah, they don't corrupt a directory, but you can create or delete "about ten" files in a single directory before the operations starts being refused. That's really pretty useless.
The parent is only "informative" in the weakest sense. Yes, a patent application must contain detail sufficient for a third party to replicate your invention. However, that detail is utterly useless until either the patent expires or an infringement case comes before a court. In particular, if I hold a patent on process X, then I hold a grant patent to bar any comer from constructing any mechanism which implements the patented process. (Bear in mind that the current European controversy has nothing to do with that part of patent law, but only about what properties a "patentable mechanism" must possess. The arguments against business process patenting boil down to the claim that a "process" is too broadly applicable a notion to be granted patent protection.)
Since reverse engineering necessarily requires that the engineer construct a working model, to the extent that Skype's protocols were patented, the construction of that working model would, in fact, constitute a prima facie infringement.
Just to echo and highlight what arivanov said, it sounds to me like this attack was a two-stage attack, in which a developer's machine was compromised and used as a jumping-off point for an attack on the Debian server. The strength of the developer's password was irrelevant, in that case; a root kit on the developer box would have exposed any password, however strong, or any SSL private key stored on the box.
(And, yes, there are root kits for Linux, Mac OS X, and FreeBSD, as well as for Windows. So the fact that a Debian dev is almost certainly running Debian provides no real protection.)
The parent is either the best troll I've ever read, or the stupidest piece of fanboy fiction ever propagated. I'm hoping it's a troll, because, if it is, it needs to be held up to all attempted trollers as the standard to which they should aspire.
Oh, by the way -- if there were an undetectable rootkit on OS X, how would one go about finding it?
I was very careful in my phrasing, and talked about a physical airgap between the network and the signing system. In the case of the wireless router and laptop, you're certainly protected if the laptop doesn't have a connection to an interface to the wirelss network.
You do understand that everything downloaded from update.microsoft.com needs to be digitally signed, right? In order to actually subvert the downloads, an attacker would not only need to take over the system, but would also need to sign the modified download with a Microsoft key. That's hard: the private keys for signing code are kept on a machine inside a SKIF. Last time I checked, code was taken to be signed by sneakernet, so that there would be a physical airgap between the network and the signing system.
You are taking an analog signal, and converting what was digital back to digital... what you will not get is the original quality a true digital path would have provides, indeed you would probably see some loss from the conversion.
That depends. If the cable is electronically active, the digital signal could be transmitted on a side-band which was turned on by a firmware upgrade. In that case, MS could, indeed, provide a digital signal with the current hardware for those who wanted to buy a cable.
Slashdot Mirror
You don't, and you never have. What you might have needed was a license to make a copy of software (a "game save") or something like that. You might have included copyrighted code in the patch you uploaded into the system. Again, that would need a license. But to mod your hardware? No license is, or ever has been, necesary.
Actaully, Moglin, in particular, has made comments about how Linux would be automatically relicencsed and the like. The FSF is trying very hard to enforce its will on Linus, against his will.
Me, I think that shows a really interesting use of the word "freedom". "All software is free, but Gnu's is more freer than others", or something like that.
Actually, for a while, the FSF maintained that the output of Bison was, in fact, automatically GPL'ed. I don't know if they still maintain that position, but they certainly did claim that the output of a compiler could be automatically subject to GPL.
I don't understand what you mean by "the claims for foreign markets seem patently false as the 360 [goes]." Which claims are you talking about? The PS2/360 outside the United States? The claims that the 360 has sold as many as it has?
http://www.videogamecharts.com/ is my source.
You're changing the subject. Sure, the 360 is doing terribly in Japan. That doesn't speak to whether (a) it's worth producing games for the console or (b) whether Microsoft's sales figure are valid or not. For the first of these, the Japanese market is a write-off for non-Japanese development houses, which covers Microsoft's main producers, so the only question is whether game developers can target the US and Europe, and still make money. As to the second, there's no way to refute it; it's the definition of sales for Microsoft.
Nope. MS does not benefit from the subsequent sale.
You ask "B-b-but, what about third party developers? What about games?" Again, you're looking at the question wrong. The question of how many consoles sell is only tangentially of interest to Microsoft any more. The question that drive third party developers is not "how many consoles will sell to consumers", but "will enough consoles eventually sell to consumers to make it worth developing games," and, as we've already seen, the answer to that is "yes". Between the delays in the PS3 and the number of 360's which have already sold, the console is worth taking a risk on.
As far a MS is concerned, those *are* sales. The retailer may or may not actually hand the product off to a customer, but Microsoft doesn't benefit from that subsequent retail transaction.
Sorry, fan-boi, but MS is quoting the relevant figure here, much as you'd like to displarage it.
What the article said is the the Ministry of Defense researchers were able to run malicious code through OO.o without a warning -- by design. That's the equivalent of the IE design flaw in which a control could be loaded w/out user intervention, and then queried to see if it was safe for scripting -- before there was any evidence one way or another. Would you claim thatthe IE flaw wasn't a catastrophic design error?
Actually, if Ars Technica is to be believed, the French Office of Defense has done a comparitive security analysis, and Open Office lost badly. The kinds of bugs the OO.o had were design bugs; these are file handling bugs. If equivalent design bugs existed in Office, they'd be the ones exploited, not the harder to find and exploit data validation bugs.
It does not, and has not done so in Office 95, which was released eleven years ago. Check your task manager display.
There was a famous theft in which a large number of antique chairs were stolen from an office in broad daylight during working hours, with the staff present.
The thieves drove up in a moving truck, wearing appropriate clothes, and explained that the chairs were being transferred to a different office. They presented "requisitions" to sign, got signatures, filled the truck, and dorve away.
If you look back at the original NT 3.1 documentation, there's an extensive discussion of how different window messages are handled (it depends on their WM_ value, FWIW.) The fact that any window can be a target for any message is documented there, along with the security consequences of that decision.
Bottom line: shatter is real, but only for incorrectly designed applications.
Actually, no, the Network DDE service had such a window back in 1998. That bug -- which was a real excalation of priviledge defect, found by the author of BackOrifice -- was fixed back then. The original shatter vulnerability was found two years later, and, amusingly, didn't involve any Windows component; rather, it had to do with a third-party virus scanning application.
COM was restructured so that DDE didn't a service-associated window, avoiding the privilege attack.
Actually, it is not a "grave design error". A properly designed service should have no window handlers in the privileged process, and should communicate with any other process through a shared memory interface. The desktop is the security boundary on Windows for window messages, not the window.
Well, actually, the Windows .exe is only 29.2MB, but it requires a mandatory optional 11GB download called "requiredoptionalresources.dll", which is a pure resource DLL.
For Linux, of course, you need to d/l the entire tarball.
Yeah, they don't corrupt a directory, but you can create or delete "about ten" files in a single directory before the operations starts being refused. That's really pretty useless.
The parent is only "informative" in the weakest sense. Yes, a patent application must contain detail sufficient for a third party to replicate your invention. However, that detail is utterly useless until either the patent expires or an infringement case comes before a court. In particular, if I hold a patent on process X, then I hold a grant patent to bar any comer from constructing any mechanism which implements the patented process. (Bear in mind that the current European controversy has nothing to do with that part of patent law, but only about what properties a "patentable mechanism" must possess. The arguments against business process patenting boil down to the claim that a "process" is too broadly applicable a notion to be granted patent protection.)
Since reverse engineering necessarily requires that the engineer construct a working model, to the extent that Skype's protocols were patented, the construction of that working model would, in fact, constitute a prima facie infringement.
Just to echo and highlight what arivanov said, it sounds to me like this attack was a two-stage attack, in which a developer's machine was compromised and used as a jumping-off point for an attack on the Debian server. The strength of the developer's password was irrelevant, in that case; a root kit on the developer box would have exposed any password, however strong, or any SSL private key stored on the box.
(And, yes, there are root kits for Linux, Mac OS X, and FreeBSD, as well as for Windows. So the fact that a Debian dev is almost certainly running Debian provides no real protection.)
The parent is either the best troll I've ever read, or the stupidest piece of fanboy fiction ever propagated. I'm hoping it's a troll, because, if it is, it needs to be held up to all attempted trollers as the standard to which they should aspire.
Oh, by the way -- if there were an undetectable rootkit on OS X, how would one go about finding it?
I was very careful in my phrasing, and talked about a physical airgap between the network and the signing system. In the case of the wireless router and laptop, you're certainly protected if the laptop doesn't have a connection to an interface to the wirelss network.
You do understand that everything downloaded from update.microsoft.com needs to be digitally signed, right? In order to actually subvert the downloads, an attacker would not only need to take over the system, but would also need to sign the modified download with a Microsoft key. That's hard: the private keys for signing code are kept on a machine inside a SKIF. Last time I checked, code was taken to be signed by sneakernet, so that there would be a physical airgap between the network and the signing system.