It's a bug in the font rendering component, which apparently lives in kernel space. PDFs are allowed to embed fonts, and apparently Preview doesn't verify the font data before tossing it to the renderer. Apparently the renderer doesn't verify it either, because instead of rejecting the data as invalid, it gives the attacker completely unrestricted control over the software.
PDFs having embedded fonts is a very useful and entirely reasonable feature. It would help if Preview validated the fonts, but that's not entirely required (you could validate somewhere further down the pipeline, so long as you don't try to process the unvalidated data). There are several other ways to remotely load fonts, ranging from other document formats to the Web Open Font Format (http://www.w3.org/Submission/2010/03/) and some CSS in a web page. There's a decent chance that at least a few others are vulnerable to this exploit. However, there's been considerable research recently into Apple's PDF reader, with one researcher finding 60 different exploitable bugs in the software (though most of them probably aren't kernel). By comparison, the same testing data found three exploitable bugs in Adobe Reader.
Having font rendering/rasterizing in the kernel is... not brilliant, but not inherently a critical security flaw. It's certainly possible to do in userland, and probably safer, but displaying text is something that almost every app will need to do at some point, and putting it in the kernel will minimize memory footprint and maximize performance. The real WTF here is that the data isn't being validated extremely carefully as soon as it enters the kernel, and possibly before. When kernel-mode code starts parsing unvalidated data, the best you can really hope for is that you get a kernel-mode crash and are forced to do a hard reboot (on Windows, this would be a BSOD).
It's OK, on Apple products remote elevation-of-privilege exploits with remote code execution are only used for *GOOD* things, like giving you control of the shiny little handheld computer you bought.
They aren't talking about the InPrivate Browsing mode. IE8 has built-in adblocking, based on content that is present in many pages from the same (external) domain. This blocks tracking cookies and images/applets from advertising companies. You can also choose to manually block content.
However, this feature - called InPrivate Filtering - is disabled by default each time you run IE. You can enable it by clicking the icon in the lower right, on the status bar, immediately next to the magnifier. There's also apparently a registry key you can change to enable it by default.
Sure... or I could send you an email with a PDF in it (which is the attack vector that this remote exploit^W^Wjailbreak uses) and completley take over your phone. Read all your mail, monitor your calls and text messages, see all your websites and intercept all your passwords, follow your GPS location (even if you think you have the GPS turned off), make copies of all your photos, videos, and other files, purchase apps for you, and send all this wealth of info back to me and anybody who wants to pay me for it. Hell, I could use your phone as part of a botnet sending spam email or DoS attacks, or as a place to store kiddie porn or other illegal data, or as an anonymous proxy to commit cybercrime (tracable back to you, and no gurther).
An iPhone is a computer, and this is a elevation of privilege arbitrary code execution vulnerability, in a component that runs without you needing to do anything in particular (I could embed the PDF in a web page and you'd get taken over just for visiting). It's the kind of security vulnerability that gives sysadmins nightmares. It's one step shy of the holy grail of exploits (remote exploit with EOP and arbitrary code that requires no user interaction at all) and can be paired with any non-interactive exploit to get that holy grail. It's the kind of thing that gets flagged CRITICAL in patch info.
The really sad thing? It's about three steps past the worst level of exploit most Mac users think is possible at all (bear in mind that most Mac users have never even heard of Slashdot) and this isn't the first such exploit to be found.
Recent talk by a security researcher at CanSecWest: Babysitting an army of monkeys: an analysis of fuzzing 4 products with 5 lines of Python - Charlie Miller, Independent Security Evaluators
The gist of it was that with a dead simple fuzz testing tool (a program that modifies valid files to produce invalid ones, then feeds the invalid files into parsers to try and break them) this guy found 60 different exploitable vulnerabilities in Apple's Preview app (their home-grown PDF reader). The same fuzzed files found only 3 exploitable holes in Adobe Reader, and triggered only 1 crash in Reader for every 95-ish in Preview.
I hate to say it, but Apple users should use Reader, *not* Preview, wherever possible. When your security is orders of magnitude worse than Adobe's, you have serious problems.
Thank you for saying this. It's always astounded me how people look at Jailbreaking as though it's a good thing that it's possible. What part of "0-day bug gives root access" (which is exactly what this is) sounds like a good thing? I've heard people tell me that they use Apple products because there are no exploits for them in the same 5 minutes that they tell me that they've jailbroken their phone, or at least considered it.
I'm glad, for the sake of people who have iPhones, that there exists a way to give them control over their shiny little handheld computers. I despair for the idiots who use Apple because "they don't get viruses [by which they mean have security vulnerabilities]" and consequently completely ignore security best practices. Yes, Apple malware is uncommon, but that's not because it's hard to write; it's because you can't make as much money exploiting OS X as you can exploiting Windows, and malware is all about profit these days. In the whitehat world, Apple has been quite conclusively demonstrated to be Swiss cheese.
Apple's security is really, really bad. I mean, seriously terrible. I have a co-worker who came by my office a week or so back witha proof of concept explot he'd found with a home-built fuzz testing tool in his own time. He's employed full-time (and it's not like our jobs involve a lot of goofing off time) and it's most definitely not to work on Apple software; it just doesn't take any significant amount of time. In a recent talk at CanSecWest, a security researcher found that Apple's PDF Preview app crashes about 100 times as often as Adobe Reader when given malformed files.[1] In roughly a million fuzzed PDF files he found 3 exploitable bugs in Adobe Reader... and 60 in Preview. When your software fares that badly in comparison to Adobe's, you should be afraid. This is not the work of a company that understands software security, and no amount of UNIX core can make up for that.
[1] Babysitting an army of monkeys: an analysis of fuzzing 4 products with 5 lines of Python - Charlie Miller, Independent Security Evaluators
Yes and no. If you're a kid in high school who wants to make some money on the weekends, knowing how to write web pages isn't a bad approach. It probably won't pay enough to really live on, though, let alone support a family on. If you already have a marketable but not computer-based skill set (business, accounting, sales, psychology, chiropractics, education, etc.) then learning to program a little is not likely to help your bottom line at all, and learning to program well is going to take time away from using the skills you already have.
Also, don't think that just because you learn how to cut some code you're going to be like your son-in-law who landed a $80K/year job right out of university; most programming jobs pay well but not usually that well, and there's no lack of well-qualified applicants for the good ones. If you want to be one of those, get yourself into a good university's computer science or engineering program, finish the degree, and polish up your interview skills; you might just get lucky. If that sounds too much like learning an entirely new career to you, congrats, you figured it out.
Don't get me wrong, learning about computers (how to maintain them, how to stay secure, how to recognize when there's a problem, and ideally how to fix the most common issues) is almost essential in today's world, much like the same general class of skills are relevant to cars, houses, and financial accounts. If you want to go a bit further, learning to write Office macros and/or shell scripts (CMD or Powershell on Windows, or Bash) is actually a really handy productivity skill. It's not glamorous, it's (hopefully) not anything a customer will ever directly see, and it's not going to give you the programming skills to write the next Facebook. However, it is programming, and of the most immediately useful type: it can easily save you hundreds of hours a year of tedious tasks, and let you put that time to more productive use.
By your arguments, laws against murder for cannibalism are "artificially increasing the cost of food" and constitutes "Telling a family Africa that they have to watch their children die of malnourishment, exposure to the elements and disease because we're going to make it too expensive for them to afford [food]." Just because coal is cheap in dollars doesn't mean that it is a net benefit to use it for power. The ends of ensuring everybody has power for a few cents less per kWh do not justify the costs of utilizing such an incredibly destructive and harmful energy source. It comes closer to being justifiable than slaughtering human beings for their meat, but it's the same flawed argument in the end. Just as we can farm food, we can construct fission breeder reactors that will use our existing nuclear waste as fuel, and for less long-term cost than coal (plus they actually release *less* radiation into the atmosphere, and fueling them is safer).
As for your second argument, remember that the "historical record" you speak of points to times when the planet warmed naturally. We're actually in the middle of what should be a colder period in history. If you accept as reasonable the assertion that man-made factors are contributing to global warming, you need to consider the impact that has on the claim that the planet is (unnaturally) warming to a point of damage. What happens when we re-enter a period where the planet naturally warms? What about the risk of increasing the greenhouse effect and reducing our ability to control it so much that we enter a runaway chain reaction? Just because there have been historically warmer periods does not mean that it's safe to be this warm now.
Holy crap, you call that a fix? That's an incredibly hackish work-around to an atrocious bug that should never have seen the light of day in the first place, which is triggered in a "feature" that would have failed design review guidelines by anybody moderately competant. What's more, it'll prbably stay there for months if not years, instead of fixing the hideious underlying problems.
For those who are curious: the atrocious bug is that finding a short and completely valid (as in, well formed and not in violation of any spec) unexpected string in the runtime will *CRASH* your IDE. To add insult to injury, the crash error doesn't give any clue as to what the problem is, in fact suggests a completely different issue (that your computer has too little RAM, which admittedly might be true if you tried to run Eclipse on something without a couple gigs). The incredibly incompetant design error was relying on a hard-coded string to identify your runtime, instead of using it as a vague hint at best. Among other things, Reflection is perfectly suited to determining the runtime's capabilities. Strings change, and the incredible clusterfuck that is a modern browser's User Agent string (not to mention the similarly incredible clusterfuck that results from servers trying to customize their code for that string) should have been more than enough warning that this was a terrible idea.
I'm much, much less concerned about the fact that they were looking for a hard-coded string (this is idiotic, but not technically bad programming) as that the application *CRASHES* if it doesn't find it! This is the kind of thing that makes me doubt the truth of the "many eyes" theory of bug-hunting; there's simply no excuse whatsoever for an "out of memory" crash in a situation like this. At worst, you should get an unhandled "UnrecognizedJvmException" or some such BS, which of course *should* have been caught, but at least would make sense. Out of memory?!? Who the hell wrote the POS that's triggering that, and why hasn't anybody else caught the fact that if it doesn't find what it's looking for it apparently blows its entire memory allotment?
Hell, the original WarCraft had LAN play (limited to 1v1 since the game only supported two players, but still perfectly playable).
WarCraft 2 was definitely the game that first showed the potential of the 'Craft multiplayer paradigm. It supported 8 players, came with a decent number of multiplayer maps and an editor (the expansion added a crapload of new maps), supported team play, and was very popular in multiplayer - I spent far, FAR too many hours on Microsoft's Internet Gaming Zone, using the PX-over-IP functionality to play a bunch of WC2 games. The editor was nothing on StarCraft's, let alone WC3's (most notably, no trigger scripting) but there were still some good custom maps for it that weren't the standard RTS design.
It is, so the tagger isn't actually misinformed. That said, the source license is still almost completely irrelevant to the story. It's cool to point it out, but that's not what this story is about (to the extent that it's about much at all...)
Sounds like your domain controller may be running an old version of Windows Server... update to 2008 (R2, ideally) and/or disable the legacy hash; if you don't have legacy clients you really don't want to keep storing the legacy hash because it really is easy to break. I think all versions of Windows from 2000 up *can* use the new hash algorithm.
I've used T-Mobile (through roaming, but they didn't charge extra for it) in tiny, almost-unknown towns in rural northern CA (Somes Bar). I suppose it's still "near an ocean" (2 hour drive), but the population count is like 43 or something.
Of course, I didn't have texts or voicemail (and this wasn't a smartphone, but I'm guessing I wouldn't have had data) but the phone itself still worked.
I'm opposed to Halliburton and definitely feel they should pay their part of the consequences, but the impression I got was that the people actually operating the rig were ordered by BP higher-ups to violate all manner of safety guidelines. Again, not saying Halliburton is blameless here, but I'm not sure they did anything actually wrong, or even less than they should, except for letting the BP people have any say regarding such incredibly stupid ideas as replacing drilling mud with seawater.
Aside from needing to wait until the game I want to play is actually available at that price, you mean. A store that sells everything for 5%-10% more than I can find it elsewhere, except for a few items a week (which are only occasionally things I want) is still an expensive store, though it's one worth checking out now and then to see what their sales are. Basically, Steam is a good choice for impulse buys, but it's not usually a good choice for "I want to play game X, let's see what it costs."
Mind you, this is not inherently a bad way to run a business. Woot.com seems to do just fine dropping items (few of which are even remotely interesting to me) low enough in price that the ones I actually want become impulse buys. Just don't confuse "we always have a sale on something or other" with "our store has really good prices."
Foxit is nice, but they just don't *get* security. At all. I mean, a fairly basic dumb fuzzer (change a random byte here and there in a template file) will reveal it to be Swiss cheese in a couple hours. This is not to say that I like Acrobat Reader or think its security is good, but its security is, in fact, a hell of a lot better than Foxit's. As with MS software, Adobe is the big target that everybody goes for, so they can be 10 times as secure and still have far more actual exploits.
Integrity Levels, while not configurable in the sense of AppArmor profiles, serve much the same purpose (low-integrity apps, like IE, can't write files outside of low-integrity locations like the Temporary Internet Files directory, can't directly invoke apps with higher integrity levels, and can't use various forms of IPC to higher-integrity processes; this is what Protected Mode is all about). It would be nice if there were more control over things like ILs, but that's largely why Windows has a bunch of user accounts with names like NetworkServiceNoImpersonation and SqlServer: you run potentially vulnerable programs under those accounts, then use NT's fine-grained permissions structure to grant those accounts just enough access to just the objects that they need access to. In the end, it solves the same problem, but it is tricky to do that for interactive programs like a browser or PDF reader.
Quick point: The 15+ characters on Windows rule is outdated (not that short passwords are a good idea anyhow). The old hash algorithm was absurdly easy to brute-force (there are free downloads that will do it in 3 minutes or less) and is disabled by default on all Windows systems from Vista forward (possibly also 2003, I'm not sure). I believe it can be re-enabled for backward compatibility, and it may be possible to disable on XP (check the Local Security Policy management console, perhaps) but yes, there are downsides to using a legacy OS, such as legacy hashing algorithms used for security.
I'm not actually sure I'd call Steam's prices "excellent" aside from their frequent sales. Sales are nice, of course, but overall I've found Steam to typically be a little bit above what I can find from online retailers, and occasionally above what I can find on a physical shelf. I very rarely buy Steam games at more than half their list price; it's just not worth it. They also charge just as much for new titles as anywhere else, which is to say they charge a hell of a lot for new releases (over $60 for a single game with under 50 hours of unique playthrough seems really, really lame to me).
Technically possible, but a pain in several ways, from keeping track of all those accounts (and needing to sign in and out a lot) to the fact that your achievements will be only on one game at a time. Besides, as you point out, it *is* possible... so why doesn't Steam let you do this? They don't even have to facilitate the process of making a sale; just let me transfer a game from my account to somebody else's (that person would need to use Steam to play it, so copyrights are preserved). Obviously it would be nice if they would also take care of the money end of things (so long as I could also send games for free) but that's not critical.
So you care, at least a little bit, about whether or not there's a Mac version?
Seriously, people, think about what you're writing. That severely overused phrase just does *NOT* mean what you seem to think it does. It's not like you need a PhD in English to figure out the difference between "I could care less" and "I couldn't care less." So, which one did you mean to use?
On-topic, it does seem strange that they wouldn't have ported it to OS X. In theory, a cross-platform game engine should make the port very easy...
Which is, of course, DRM. It's a pretty benign form of DRM - my only serious objection is the inability to re-sell games - but it most certainly is DRM. If Steam were really just distributing games, and nothing more, I could copy the distributed bits to another computer and run them from there, without Steam even being installed. Steam is very good at what it does, but do *NOT* make the mistake of assuming just because it's better than the majority of DRM schemes that it isn't a DRM scheme itself.
Slashdot Mirror
It's a bug in the font rendering component, which apparently lives in kernel space. PDFs are allowed to embed fonts, and apparently Preview doesn't verify the font data before tossing it to the renderer. Apparently the renderer doesn't verify it either, because instead of rejecting the data as invalid, it gives the attacker completely unrestricted control over the software.
PDFs having embedded fonts is a very useful and entirely reasonable feature. It would help if Preview validated the fonts, but that's not entirely required (you could validate somewhere further down the pipeline, so long as you don't try to process the unvalidated data). There are several other ways to remotely load fonts, ranging from other document formats to the Web Open Font Format (http://www.w3.org/Submission/2010/03/) and some CSS in a web page. There's a decent chance that at least a few others are vulnerable to this exploit. However, there's been considerable research recently into Apple's PDF reader, with one researcher finding 60 different exploitable bugs in the software (though most of them probably aren't kernel). By comparison, the same testing data found three exploitable bugs in Adobe Reader.
Having font rendering/rasterizing in the kernel is... not brilliant, but not inherently a critical security flaw. It's certainly possible to do in userland, and probably safer, but displaying text is something that almost every app will need to do at some point, and putting it in the kernel will minimize memory footprint and maximize performance. The real WTF here is that the data isn't being validated extremely carefully as soon as it enters the kernel, and possibly before. When kernel-mode code starts parsing unvalidated data, the best you can really hope for is that you get a kernel-mode crash and are forced to do a hard reboot (on Windows, this would be a BSOD).
That's the Apple stance on kernel-level remote code execution exploits: It Just Works!
It's OK, on Apple products remote elevation-of-privilege exploits with remote code execution are only used for *GOOD* things, like giving you control of the shiny little handheld computer you bought.
</sarcasm> just in case anybody was wondering.
They aren't talking about the InPrivate Browsing mode. IE8 has built-in adblocking, based on content that is present in many pages from the same (external) domain. This blocks tracking cookies and images/applets from advertising companies. You can also choose to manually block content.
However, this feature - called InPrivate Filtering - is disabled by default each time you run IE. You can enable it by clicking the icon in the lower right, on the status bar, immediately next to the magnifier. There's also apparently a registry key you can change to enable it by default.
Sure... or I could send you an email with a PDF in it (which is the attack vector that this remote exploit^W^Wjailbreak uses) and completley take over your phone. Read all your mail, monitor your calls and text messages, see all your websites and intercept all your passwords, follow your GPS location (even if you think you have the GPS turned off), make copies of all your photos, videos, and other files, purchase apps for you, and send all this wealth of info back to me and anybody who wants to pay me for it. Hell, I could use your phone as part of a botnet sending spam email or DoS attacks, or as a place to store kiddie porn or other illegal data, or as an anonymous proxy to commit cybercrime (tracable back to you, and no gurther).
An iPhone is a computer, and this is a elevation of privilege arbitrary code execution vulnerability, in a component that runs without you needing to do anything in particular (I could embed the PDF in a web page and you'd get taken over just for visiting). It's the kind of security vulnerability that gives sysadmins nightmares. It's one step shy of the holy grail of exploits (remote exploit with EOP and arbitrary code that requires no user interaction at all) and can be paired with any non-interactive exploit to get that holy grail. It's the kind of thing that gets flagged CRITICAL in patch info.
The really sad thing? It's about three steps past the worst level of exploit most Mac users think is possible at all (bear in mind that most Mac users have never even heard of Slashdot) and this isn't the first such exploit to be found.
Recent talk by a security researcher at CanSecWest: Babysitting an army of monkeys: an analysis of fuzzing 4 products with 5 lines of Python - Charlie Miller, Independent Security Evaluators
The gist of it was that with a dead simple fuzz testing tool (a program that modifies valid files to produce invalid ones, then feeds the invalid files into parsers to try and break them) this guy found 60 different exploitable vulnerabilities in Apple's Preview app (their home-grown PDF reader). The same fuzzed files found only 3 exploitable holes in Adobe Reader, and triggered only 1 crash in Reader for every 95-ish in Preview.
I hate to say it, but Apple users should use Reader, *not* Preview, wherever possible. When your security is orders of magnitude worse than Adobe's, you have serious problems.
Thank you for saying this. It's always astounded me how people look at Jailbreaking as though it's a good thing that it's possible. What part of "0-day bug gives root access" (which is exactly what this is) sounds like a good thing? I've heard people tell me that they use Apple products because there are no exploits for them in the same 5 minutes that they tell me that they've jailbroken their phone, or at least considered it.
I'm glad, for the sake of people who have iPhones, that there exists a way to give them control over their shiny little handheld computers. I despair for the idiots who use Apple because "they don't get viruses [by which they mean have security vulnerabilities]" and consequently completely ignore security best practices. Yes, Apple malware is uncommon, but that's not because it's hard to write; it's because you can't make as much money exploiting OS X as you can exploiting Windows, and malware is all about profit these days. In the whitehat world, Apple has been quite conclusively demonstrated to be Swiss cheese.
Apple's security is really, really bad. I mean, seriously terrible. I have a co-worker who came by my office a week or so back witha proof of concept explot he'd found with a home-built fuzz testing tool in his own time. He's employed full-time (and it's not like our jobs involve a lot of goofing off time) and it's most definitely not to work on Apple software; it just doesn't take any significant amount of time. In a recent talk at CanSecWest, a security researcher found that Apple's PDF Preview app crashes about 100 times as often as Adobe Reader when given malformed files.[1] In roughly a million fuzzed PDF files he found 3 exploitable bugs in Adobe Reader... and 60 in Preview. When your software fares that badly in comparison to Adobe's, you should be afraid. This is not the work of a company that understands software security, and no amount of UNIX core can make up for that.
[1] Babysitting an army of monkeys: an analysis of fuzzing 4 products with 5 lines of Python - Charlie Miller, Independent Security Evaluators
Yes and no. If you're a kid in high school who wants to make some money on the weekends, knowing how to write web pages isn't a bad approach. It probably won't pay enough to really live on, though, let alone support a family on. If you already have a marketable but not computer-based skill set (business, accounting, sales, psychology, chiropractics, education, etc.) then learning to program a little is not likely to help your bottom line at all, and learning to program well is going to take time away from using the skills you already have.
Also, don't think that just because you learn how to cut some code you're going to be like your son-in-law who landed a $80K/year job right out of university; most programming jobs pay well but not usually that well, and there's no lack of well-qualified applicants for the good ones. If you want to be one of those, get yourself into a good university's computer science or engineering program, finish the degree, and polish up your interview skills; you might just get lucky. If that sounds too much like learning an entirely new career to you, congrats, you figured it out.
Don't get me wrong, learning about computers (how to maintain them, how to stay secure, how to recognize when there's a problem, and ideally how to fix the most common issues) is almost essential in today's world, much like the same general class of skills are relevant to cars, houses, and financial accounts. If you want to go a bit further, learning to write Office macros and/or shell scripts (CMD or Powershell on Windows, or Bash) is actually a really handy productivity skill. It's not glamorous, it's (hopefully) not anything a customer will ever directly see, and it's not going to give you the programming skills to write the next Facebook. However, it is programming, and of the most immediately useful type: it can easily save you hundreds of hours a year of tedious tasks, and let you put that time to more productive use.
By your arguments, laws against murder for cannibalism are "artificially increasing the cost of food" and constitutes "Telling a family Africa that they have to watch their children die of malnourishment, exposure to the elements and disease because we're going to make it too expensive for them to afford [food]." Just because coal is cheap in dollars doesn't mean that it is a net benefit to use it for power. The ends of ensuring everybody has power for a few cents less per kWh do not justify the costs of utilizing such an incredibly destructive and harmful energy source. It comes closer to being justifiable than slaughtering human beings for their meat, but it's the same flawed argument in the end. Just as we can farm food, we can construct fission breeder reactors that will use our existing nuclear waste as fuel, and for less long-term cost than coal (plus they actually release *less* radiation into the atmosphere, and fueling them is safer).
As for your second argument, remember that the "historical record" you speak of points to times when the planet warmed naturally. We're actually in the middle of what should be a colder period in history. If you accept as reasonable the assertion that man-made factors are contributing to global warming, you need to consider the impact that has on the claim that the planet is (unnaturally) warming to a point of damage. What happens when we re-enter a period where the planet naturally warms? What about the risk of increasing the greenhouse effect and reducing our ability to control it so much that we enter a runaway chain reaction? Just because there have been historically warmer periods does not mean that it's safe to be this warm now.
Holy crap, you call that a fix? That's an incredibly hackish work-around to an atrocious bug that should never have seen the light of day in the first place, which is triggered in a "feature" that would have failed design review guidelines by anybody moderately competant. What's more, it'll prbably stay there for months if not years, instead of fixing the hideious underlying problems.
For those who are curious: the atrocious bug is that finding a short and completely valid (as in, well formed and not in violation of any spec) unexpected string in the runtime will *CRASH* your IDE. To add insult to injury, the crash error doesn't give any clue as to what the problem is, in fact suggests a completely different issue (that your computer has too little RAM, which admittedly might be true if you tried to run Eclipse on something without a couple gigs). The incredibly incompetant design error was relying on a hard-coded string to identify your runtime, instead of using it as a vague hint at best. Among other things, Reflection is perfectly suited to determining the runtime's capabilities. Strings change, and the incredible clusterfuck that is a modern browser's User Agent string (not to mention the similarly incredible clusterfuck that results from servers trying to customize their code for that string) should have been more than enough warning that this was a terrible idea.
I'm much, much less concerned about the fact that they were looking for a hard-coded string (this is idiotic, but not technically bad programming) as that the application *CRASHES* if it doesn't find it! This is the kind of thing that makes me doubt the truth of the "many eyes" theory of bug-hunting; there's simply no excuse whatsoever for an "out of memory" crash in a situation like this. At worst, you should get an unhandled "UnrecognizedJvmException" or some such BS, which of course *should* have been caught, but at least would make sense. Out of memory?!? Who the hell wrote the POS that's triggering that, and why hasn't anybody else caught the fact that if it doesn't find what it's looking for it apparently blows its entire memory allotment?
Hell, the original WarCraft had LAN play (limited to 1v1 since the game only supported two players, but still perfectly playable).
WarCraft 2 was definitely the game that first showed the potential of the 'Craft multiplayer paradigm. It supported 8 players, came with a decent number of multiplayer maps and an editor (the expansion added a crapload of new maps), supported team play, and was very popular in multiplayer - I spent far, FAR too many hours on Microsoft's Internet Gaming Zone, using the PX-over-IP functionality to play a bunch of WC2 games. The editor was nothing on StarCraft's, let alone WC3's (most notably, no trigger scripting) but there were still some good custom maps for it that weren't the standard RTS design.
It is, so the tagger isn't actually misinformed. That said, the source license is still almost completely irrelevant to the story. It's cool to point it out, but that's not what this story is about (to the extent that it's about much at all...)
Sounds like your domain controller may be running an old version of Windows Server... update to 2008 (R2, ideally) and/or disable the legacy hash; if you don't have legacy clients you really don't want to keep storing the legacy hash because it really is easy to break. I think all versions of Windows from 2000 up *can* use the new hash algorithm.
I've used T-Mobile (through roaming, but they didn't charge extra for it) in tiny, almost-unknown towns in rural northern CA (Somes Bar). I suppose it's still "near an ocean" (2 hour drive), but the population count is like 43 or something.
Of course, I didn't have texts or voicemail (and this wasn't a smartphone, but I'm guessing I wouldn't have had data) but the phone itself still worked.
I'm opposed to Halliburton and definitely feel they should pay their part of the consequences, but the impression I got was that the people actually operating the rig were ordered by BP higher-ups to violate all manner of safety guidelines. Again, not saying Halliburton is blameless here, but I'm not sure they did anything actually wrong, or even less than they should, except for letting the BP people have any say regarding such incredibly stupid ideas as replacing drilling mud with seawater.
Aside from needing to wait until the game I want to play is actually available at that price, you mean. A store that sells everything for 5%-10% more than I can find it elsewhere, except for a few items a week (which are only occasionally things I want) is still an expensive store, though it's one worth checking out now and then to see what their sales are. Basically, Steam is a good choice for impulse buys, but it's not usually a good choice for "I want to play game X, let's see what it costs."
Mind you, this is not inherently a bad way to run a business. Woot.com seems to do just fine dropping items (few of which are even remotely interesting to me) low enough in price that the ones I actually want become impulse buys. Just don't confuse "we always have a sale on something or other" with "our store has really good prices."
Foxit is nice, but they just don't *get* security. At all. I mean, a fairly basic dumb fuzzer (change a random byte here and there in a template file) will reveal it to be Swiss cheese in a couple hours. This is not to say that I like Acrobat Reader or think its security is good, but its security is, in fact, a hell of a lot better than Foxit's. As with MS software, Adobe is the big target that everybody goes for, so they can be 10 times as secure and still have far more actual exploits.
Integrity Levels, while not configurable in the sense of AppArmor profiles, serve much the same purpose (low-integrity apps, like IE, can't write files outside of low-integrity locations like the Temporary Internet Files directory, can't directly invoke apps with higher integrity levels, and can't use various forms of IPC to higher-integrity processes; this is what Protected Mode is all about). It would be nice if there were more control over things like ILs, but that's largely why Windows has a bunch of user accounts with names like NetworkServiceNoImpersonation and SqlServer: you run potentially vulnerable programs under those accounts, then use NT's fine-grained permissions structure to grant those accounts just enough access to just the objects that they need access to. In the end, it solves the same problem, but it is tricky to do that for interactive programs like a browser or PDF reader.
Quick point: The 15+ characters on Windows rule is outdated (not that short passwords are a good idea anyhow). The old hash algorithm was absurdly easy to brute-force (there are free downloads that will do it in 3 minutes or less) and is disabled by default on all Windows systems from Vista forward (possibly also 2003, I'm not sure). I believe it can be re-enabled for backward compatibility, and it may be possible to disable on XP (check the Local Security Policy management console, perhaps) but yes, there are downsides to using a legacy OS, such as legacy hashing algorithms used for security.
You do also have to pay for that one... but then again, that really is to be expected.
I'm not actually sure I'd call Steam's prices "excellent" aside from their frequent sales. Sales are nice, of course, but overall I've found Steam to typically be a little bit above what I can find from online retailers, and occasionally above what I can find on a physical shelf. I very rarely buy Steam games at more than half their list price; it's just not worth it. They also charge just as much for new titles as anywhere else, which is to say they charge a hell of a lot for new releases (over $60 for a single game with under 50 hours of unique playthrough seems really, really lame to me).
Technically possible, but a pain in several ways, from keeping track of all those accounts (and needing to sign in and out a lot) to the fact that your achievements will be only on one game at a time. Besides, as you point out, it *is* possible... so why doesn't Steam let you do this? They don't even have to facilitate the process of making a sale; just let me transfer a game from my account to somebody else's (that person would need to use Steam to play it, so copyrights are preserved). Obviously it would be nice if they would also take care of the money end of things (so long as I could also send games for free) but that's not critical.
So you care, at least a little bit, about whether or not there's a Mac version?
Seriously, people, think about what you're writing. That severely overused phrase just does *NOT* mean what you seem to think it does. It's not like you need a PhD in English to figure out the difference between
"I could care less"
and
"I couldn't care less."
So, which one did you mean to use?
On-topic, it does seem strange that they wouldn't have ported it to OS X. In theory, a cross-platform game engine should make the port very easy...
Which is, of course, DRM. It's a pretty benign form of DRM - my only serious objection is the inability to re-sell games - but it most certainly is DRM. If Steam were really just distributing games, and nothing more, I could copy the distributed bits to another computer and run them from there, without Steam even being installed. Steam is very good at what it does, but do *NOT* make the mistake of assuming just because it's better than the majority of DRM schemes that it isn't a DRM scheme itself.