Half-Life 2 Delayed Following Code Leak

jhol writes "CNN is reporting that Half-Life 2 is delayed "by at least four months, that is to April 2004.", due to the code leak. VU Games has already suffered a 29% fall in revenue and an operating loss of $61.36 million this year. A Christmas release of Half-Life 2 would probably have been most welcomed." Update: 10/07 20:38 GMT by S : CNN Money are now reporting there's a newly public leak, allegedly involving a partially playable, Beta pre-release of the game.

Comments

Still haven't learned their lessons

[Alcimedes]

I have to wonder how long until people start to realize that for truly critical (read millions of dollars) work, you're best off having the production machines OFFLINE.

It would be a pain in the ass only being able to code on one machine, but even something as simple as a KVM switch would make it tolerable.

No internet, and none of this stuff is a problem. Not to mention you can keep working while various worms/viruses make their rounds.

The 'net is just too insecure these days, especially if you're running some version of Windows.

Re:Still haven't learned their lessons

[javatips]

One can use VMWare to do that. All VMs can have a virtual networks which will not be accessible from the host. No need for many computers and/or physical connection.

The folks at the NSA use VMWare for this purpose (they do have a special version with additional security features)

I bet that they will try to enforce that kind of separation (virtual or physical) anyway. By missing the Holiday season, they will loose a bundle on sales.

Re:Still haven't learned their lessons

[javatips]

This should not be a big problem as the VM is isolated from the host (it would take far more serious hacking, that what was done to get HL2 code, to get inside VMWare internals). One could always snif the physical ethernet card for packed, but having the VM connect through VPN to the "DEV" network would solve the problem. The host could be a barebone linux Install without any open ports. That would limit the risk of having the Host being hacked. Now you have a closed down host with two VM. One on a "private" network, and the other on "public" network.

Having a seperate machine on a seperate physical network would be more secure, but would cost much more than the VMWare approach.

Re:Still haven't learned their lessons

[Xzzy]

> How hard can it be to have a closed network for all coding purposes?

Oddly enough, as obvious as this seems, people are actually quite resistant to it. I've worked at two software development houses, and while that's not a terribly accurate representation of the entire industry, they both had the exact same attitude: "No, we don't need the dev machines on a private network, we're fine like it is.".

At one of them, I suggested it as a solution in response to a similar situation; source got into the wrong hands. Even then they said they didn't want to do it, they preferred to rely on employee training and discipline.

Whether it's indifference or ignorance, who knows. Common sense isn't, I guess. :p

Re:Still haven't learned their lessons

[PainKilleR-CE]

The initial interviews with Gabe Newell stated that someone had hacked their systems, installed key loggers, and so on, then had accessed the source repository from off-site, using the login information gathered from the key loggers to checkout the source tree.

No one had to email source code anywhere. Besides, with source that size (or even smaller), it's far easier to just burn a CD and take it with you, or log in remotely and download only what you need.

Re:Still haven't learned their lessons

[CyberGarp]

The folks at the NSA use VMWare for this purpose (they do have a special version with additional security features).

How do you know this?

It's known that the NSA uses VMWare, but they're very tight lipped about how. Also if a VMWare image is sitting on a disk, that's on an OS that's on the network. Doesn't that make the image just as vunerable? I guess one could encrypt it, but still I think the original idea of a KVM is far more secure. If it's not on the net, or a completely private net with no outside connection, then it can only be pilfered by sneaker net.

Re:Still haven't learned their lessons

[badasscat]

I have to wonder how long until people start to realize that for truly critical (read millions of dollars) work, you're best off having the production machines OFFLINE.

It would be a pain in the ass only being able to code on one machine, but even something as simple as a KVM switch would make it tolerable.

Pain in the ass?? Try impossible. How do you think game programming works, anyway? One guy sitting there plugging away on his work machine from 9-5? Bzzzzt. Sorry, try again. I say this as someone who works in the industry for a fairly large publisher who will remain nameless.

HL2 is a large, big-budget game with a lot of code, a lot of staff, and a tight production schedule. Some people seem to live in this fantasy-land where PC games are still coded by individual hackers locked away in their basement. Well, welcome to the real world, where dozens of people need to work on the same code in near real-time, and where work continues even while coders are out of the office or in fact out of the country.

I don't know that all of this code needed to be on one machine that was net accessible. There's probably something that could have been done to segment it among separate machines on separate VPN's, which then could have been combined to compile and run whenever a build was needed. So yes, Valve could have probably taken better precautions. But the answer is not to put all of the code on a single, closed machine - that simply doesn't work in real life. The code - at least some of it at a time - needs to be net accessible for a company in the business of making games to function these days.

It was revealed today that a third of the code was stolen, so maybe Valve actually was taking some sorts of precautions - maybe it was separated into three segments on three different machines. But that probably was not enough.

You can look at Valve's security as a whole, and maybe you will find holes that should have been plugged, but simply saying "the code should not have been net accessible!" is just not realistic.

Re:Still haven't learned their lessons

[Bios_Hakr]

A KVM is a recipe for screw-ups. Take a hint from the military. Have one open network and one closed network. The closed networks have no CD-R/RW, floppy, or other removable media. The closed network is clearly marked as closed. The closed boxen are then physicaly seperated from the public network.

Having a KVM would only be acceptable if the login script set your desktop background to a bright orange/red bitmap and a one-minute screensaver. You never know when some tool will forget what machine he is on. Having seperate monitors and keyboards can be a pain, but it's well worth it to prevent code leaks.

Re:Still haven't learned their lessons

[Kpau]

The last 2 places I've worked, every developer had TWO machines. The "development" machine was on a physically isolated network and the "office box" was the one with Internet access, email, etc. It didn't stop sneaker-net issues, but it sure stopped those little port buzzes and tickles from outside. ...and woe unto the developer that ever mixed the two. I used to do Cold War era work in the 80s... the procedures to keep delicate things isolated did not require any rocket science (outside of the frequency-isolating chickenwire that enveloped the work area). I will say as a consultant, I'm never too amazed at the LACK of prudent and simple precautions taken for critical operations at many businesses.

Re:Still haven't learned their lessons

[RabidOverYou]

Funny how you use "100% wrong" and "apparently" in the same sentence. Gabe has no clue how he got owned. Outlook buffer overflow - pfah! Could have been the creepy-looking new hire.

Re:Still haven't learned their lessons

[sqlrob]

And VMWare doesn't emulate 3D hardware worth crap. How is a cutting edge 3D game supposed to be developed with that?

Re:Still haven't learned their lessons

[rikkards]

Actually I believe the author of X-Plane does all of his development work on a mac and prefers it to a PC. I think that would be a good example of being able to do it successfully.

Re:Still haven't learned their lessons

[gorfie]

I agree that Valve should not be blamed for allowing the code to reside on a machine connected to the Net. Having the code reside on a local machine (or local network of machines) that does not have Internet access is an impractical idea.

However, I think Valve shares some of the responsibility on other aspects. The unpatched Outlook (perhaps even the use of Outlook) is definitely a problem area for such a high profile organization. If they neglected to patch Outlook, what other basic security issues were neglected by Valve? Perhaps it was something as simple as Gabe using his home computer which he left unpatched, but that's something that network admins should be aware of IMO.

I also think Valve's staff is vulnerable to social engineering. Take a quick peek at myg0t.com (skip the intro and turn off the music) and read about the various chats that were had with Valve personnel. Really simple stuff that worked.

My point: Valve should be aware that they are high profile and they should have at least taken measures to make themselves secure against basic hacking methods.

Re:Still haven't learned their lessons

[GooRoo]

Ummm... I don't think he was suggesting that you take the machines off a network, just the internet. You could quite easily have an internal network with machines/servers/other devices for development of the game by a multitude of people and a external network for machines that have internet access.

I setup all my test networks that way, Valve could certainly do the same. Sure it can be a pain, but it's the only way to go when you *really* want something secure.

Re:Still haven't learned their lessons

[bman08]

Could you use VMWare for outlook and the internet while the "real" os is only connected internally?

Re:Still haven't learned their lessons

[ComputerSlicer23]

Run the network enabled system under the VM? The VM can't access the underlying system (or shouldn't be able to). You want to search the web looking for the best AI algorithm for capture the flag, do it under the VM. You want to build and test the software? Do it under the real machine.

Kirby

Re:Still haven't learned their lessons

[RollingThunder]

You know, it is possible to have a network not connected to the Internet.

Now, if you want to allow the programmers to work from home, etc, then you do end up re-opening the system, but there's no driving business reason that it must be that way - especially since the result of a screwup can be this drastic!

I'm a closed beta tester for a game that shall remain anonymous. I was discussing the Valve situation with one of the devs in the test server, and he explained their strict "no source on net-accessible machines". Any access from the dev boxes out goes through application level proxies, such that no system ever talks direct to the outside world. It's always dev box to proxy, then proxy to the outside world.

Now, I can see a couple ways around that. If they can proxy through to the web, so can my keylogger/malware installer, for starters... but at least the intention is there.

Re:Still haven't learned their lessons

[Sinistar2k]

VMware might be great for general coding work. But what if you want to actually test something you've written? Good luck getting VMware to run your advanced 3D engine that requires a hardware accelerator (hint: it won't).

Re:Still haven't learned their lessons

[racermd]

Good point. The developers can, to a certain extent, make demands regarding their development environment. However, network security is totally in the hands of their IS/IT department, if they even have one. It's the responsibility of the IS/IT staff to maintain the computing environment everyone works in. That applies to developers, the CEO, marketing, even the secretary. The head of IS/IT must set balanced policies regarding access and security. Access should be granted on an as-needed basis, not on an as-wanted-by-CEO basis (like some companies I've worked for). [RANT]I've never understood the reasoning behind the CEO or other major department heads getting unrestricted access to everything. The people that are most visible in the company, and thus the biggest targets, are these department heads. Often, these are the same people that don't even understand the technology they've been given access to, which makes them just that more dangerous to the security and integrity of the network. I try to point out that they should have just as much access as they need to do their job, and that usually means less than their own secretary.[/RANT]

If it were me, I would have mandated a separate firewalled subnet for the developers systems and done away with Exchange/Outlook company-wide in favor of a more stable mail server. It wouldn't be completely out of the question to maintain a second mail server just for the developers inside their subnet. An enterprise-grade network-enabled virus scanning package would have been installed at the primary switch on both networks. Accessibility from the outside, including from the other subnet used by the general office staff, would be restricted to what would be absolutly required. These connections, once enabled, would be monitored and restricted to certain times of day. I'd even go so far as to implement a one-time password system with rotating keys.

With just these simple policies in place, connectivity to the outside from within is maintained, virii and trojans are dealt with (mitigated to reasonable extent, anyway), and the biggest external threats are those with the "absolutly required" access to the developer subnet from outside. It wouldn't have been totally secured against outside traffic, obviously, but the traffic that would come through should be easier to manage and detect. If it were an inside job, as some have speculated on due to lack of faith in the accounting of events Gabe provided, this would have been easier to detect, as well. Covering one's tracks is much more difficult to do if everything is separated and monitored more closely than the general traffic. Sneakernet is the only method that I have not addressed, and I can't see any reason to do anything about it. The developers would be the only staff that have regular physical access to the project's systems, so "outsiders" accessibility would be almost out of the question, assuming that the building has adequate access controls (i.e. card keys active for only certain times of day). And securing it any further would be tipping the balance of security/accessibility too far.

Also note that I'm not saying that what happened at Valve could have been prevented. A determined individual could still bypass the security measures outlined above with enough time and resources, but it would be much harder to do so. As an IS/IT manager, the focus is more on balancing security with accessibility. If the code were completely secured to outside access, development time and costs increase to the point where, possibly, it would make no business sense to even develop the game.

Re:Still haven't learned their lessons

[helmutjd]

Why is this modded up? You do realize that VMware images can be copied to another machine running another copy of VMware, and booted without further effort, right? So all it would take is for someone to compromise the host machine. A thief wouldn't need to compromise the virtual machine or sniff packets; he could just download the VM's disk image from the host machine and boot it at his leisure on his own machine.

Re:Still haven't learned their lessons

[Martin Blank]

I've seen this in developers at four different companies. Just because they can write code doesn't mean they keep up to date on their patches. A lot of developers barely know how to power on their systems, let alone when to go looking for patches. It's low priority.

Re:Still haven't learned their lessons

[LiquidCoooled]

He said they speculate that it was done via a buffer overflow in Outlook's preview pane. .

At least a couple of years old if I remember correctly.

Delayed anyways?

[kneecarrot]

I just have to wonder if a serious delay was in the works anyway and the code theft gave Valve a publicly acceptable reason.

Re:Delayed anyways?

[shird]

Yes I think this is the case. I have taken a look at the code, and I can say there is a hell of a lot of 'TODO:/BUG:' stuff in there. I'm no expert, but I would say it seemed a long way off being complete. Not to mention all the artwork, levels, scripts etc that may or may not exist in very complete form.

As for ease for creating keygens, take a look at the code - it makes an external reference to a 'cdkeycheck()' function (cdkey.obj) in which there is even comments to the effect that they (valve) don't have the source code. In other words, they have outsourced the key verification algorithm, so it doesn't exist in the source tree. (either is the cdkey.obj file).

Re:Delayed anyways?

[cK-Gunslinger]

Makes sense. There is really no reason to release the game as early as last month or even December. They really have no competition (next-gen FPS) other than Doom3, which won't show up until late next year. On top of that, they are just slightly too advanced for the current hardware out there. I mean, it appears that top-of-line hardware is required to even play the game at an acceptable rate. $400 dollars vid cards should never be *required* for a game. And don't think nVidia isn't heavily involved, either.

This is all marketing. The truth is, HL2 will have a better market 6 months down the road than in December. There will be more hype and more people woul can afford the HW to play it.

Re:Delayed anyways?

[subgeek]

maybe online play doesn't matter to you, but i'd say that online play matters a LOT to most gamers. if not "most" it is certainly safe to classify it as "millions."

they've been working on this for 5 years. it's easy to say how long YOU think it should take them to rewrite parts that were stolen. you don't have to rewrite it. you don't even know what it is they have to re-implement.

anyway, we still haven't heard from valve. before we re-invent all of their intentions, why don't we read what valve has to say about this?

Re:Delayed anyways?

[PainKilleR-CE]

moreover, IT'S A SINGLE PLAYER GAME mainly. and fuck, some id's games can be played pretty decently still on public servers when the source has been out for years

No one would still be playing Half-Life if it was selling for single player only (that being said, it's sold about 140x as many copies as there have been people playing it online).

As for id's games, Quake was completely pointless to play after the source was released. It may be significantly better now, after people have spent years working on anti-cheat software for the game, but for the year after release you couldn't join a game without at least one person using a blatantly hacked client, and who knows how many others using more subtle cheats. I didn't even bother trying Quake 2 after the source release, as I was already playing TFC (and by that time dealing with cheaters there, too).

That being said, I can only see the source release being a fairly minor delay, depending on how heavily Steam and the CD key verification need to be rewritten. For the rest of their code, they just need to be extra careful in reviewing their code for exploits, as now they have plenty of other eyes looking for anything that might be missed in the final code, and probably at least a dozen little utilities being developed to scan the HL2 binaries for anything found in that code.

Re:Delayed anyways?

[Jugalator]

You are apparently not a programmer.

*Most* released software has known bugs in it, but is released when the software is in a good enough state.

Quake 1's QuakeC API code had lots of TODO's and even comments like "Oooh really ugly hack coming up!" in the code. Yet, Quake 1 *was* released and *was* a huge success. And even the unpatched version was very playable and of release-quality.

The same goes for Doom's later released source code, etc, etc...

So, once again, pretty much all released software has bugs. Nothing wrong with that. The problem is if the software has obvious glaring bugs, but a simple TODO/BUG entry won't tell you that.

B.S.

[Anonymous Coward]

This is complete B.S. Why would having their code leaked force them to rewrite the game. Some people may say that it's due to cheat prevention... but c'mon. Security through obscurity is no security at all, if that's what they were relying on.

This is nothing more than them using this as an excuse for delaying the game - something that would have happened anyway. Also, by saying this, if they find the people that hacked their systems, they can sue for large monetary damages.

Re:B.S.

[Anonymous Coward]

Some people may say that it's due to cheat prevention... but c'mon. Security through obscurity is no security at all

The game industry is quite different in that regard. It is not mathematically possible to secure the client-server model of multiplayer gaming against cheating. You do not have control over the client, no matter what you do, so some form of cheating will always be possible.

The effects of cheating my a minority of players on a multiplayer game can be disasterous. If a cutomer's experience is an unpleasant one due to a small number of cheaters, it's only a short matter of time before they stop playing that game. Revenue from subsequent "mission packs" or monthly online subscription fees will be lost.

In the multiplayer game industry, putting the work into minimizing cheats - either in the amount of time before protocols and game internals are reverse engineered or in reducing the effects that cheating has on the gameplay of non-cheaters - pays off in additional revenue. The cheat/revenue correlation is obvious to game companies by now. This is not a theoretical thing.

Executive summary: Game security is nothing like computer security or network security. Any security is better than no security, and it's measurable in dollars.

Re:B.S.

[Anonymous Coward]

It is a MYTH that security through obscurity is not "security." Infact, it is the ONLY security you will ever get. I'm sure you are talking about source code being viewable by anyone (open source). The fact is, open source is just as insecure as closed source. That theory that open source allows many to view it which means all bugs are apparent just does not hold up. Take for example an old version of bind. Before you KNEW that there was some security issue (bug) you felt "secure." You were NEVER secure. The only hint of security came from the obscurity of the bug itself. Once the issue was widely known, it was not a security problem. Open source advocates would then jump at the chance to point out how well open source fixes security problems. This is putting the cart before the horse, so-to-speak.

The same is true for game networking code. The more obscure it is, the less likely there will be cheaters. This is NOT to say there will be NO cheaters. This says there will be MINIMAL cheaters. Right now, someone, somewhere knows of an exploit for some open source software that NOONE knows about. If that person keeps quiet, he will probably be the only one who can use the exploit. If on the other hand he posts the bug to bugtraq (or perhaps makes a famous cheat for a game.. such as OGC for Quake3) then the security issue can be resolved. This applies equally for proprietary as it does open source. The benefit of open source is that many people have the opportunity to fix the bugs once they are known. The problem with open source and gaming is that the cheaters have access to the algorithm of gameplay and can more easily figure out how to cheat.

Gaming is significantly different from your typical network security. When a player joins a game, he MUST be a trusted client. Your typical network exploits almost ALWAYS exploit a flaw from the OUTSIDE. In other words, the exploit works from the view-point of a non-trusted entity. Gaming exploits (cheats) work from the view-point of a trusted entity. Significantly different. Back in the day there used to be something known as hijacking a network connection. When this occured, the non-trusted exploit was transformed into the trusted client. Once an exploit was "trusted" by the server software, it could do damn near anything it pleased. Almost all exploitation revolves around the communication between trusted client and hosting server. Packet sniffing, IP spoofing, etc. etc. The only reason TCP/IP is "secure" is because at any given point in time it has obscure data that a 3rd party has trouble guessing. It used to be easy to spoof connections. Today it is somewhat harder.

Re:B.S.

[vadim_t]

Okay, first, you're confusing two things here. The password is simply unknown information. We're talking about the security of algorhitms here, not passwords.

Yes, if you know the password of course you can decrypt a blowfish encrypted message. However, you can't decrypt ALL of them. That's the difference between a compromised password and an insecure algorhitm.

Second, while indeed writing a secret algorhitm that is secure is indeed possible, it doesn't mean that just because you can't break it nobody can. Given two insecure algorhitms, one open and another closed it is possible that the open one will be broken in a month after it's announced by some security expert. The second one might be just as broken, but remain in use for years, at which point somebody will find a flaw and compromise much more information.

Also, open algorhitms like Blowfish and AES have been tested and reviewed by real security experts over all the world. To me, the words of Bruce Schneier have much more weight that somebody who came out of nowhere and announced their unbreakable algorhitm. If you want a concrete example, Meganet's VME "unbreakable" and non-public algorhitm has been successfully reverse-engineered, and proved to be AWFULLY broken. So broken in fact that any message can be decoded within minutes.

If you rely on obscurity, prepare for a nasty surprise. Sooner or later, some smart guy with free time will decide to debug, decompile and reverse-engineer your application. Perhaps in a week or two the algorhitm will be posted on the USENET, or a closed source exploit will appear.

You don't want a situation like above. This smart guy might very well decide to do the same as you're doing, keeping the rest of the people in the obscurity and finding a way of getting a profit from that.

Well..

[sonoluminescence]

...maybe the Valve version has been delayed.

Confused

[M.C. Hampster]

Was the code that was stolen then deleted by the thief? Why would this cause any sort of delay? This sounds like a fairly lame excuse for shipping late.

It only makes sense that code that would generate millions of dollars in revenue for Valve would be backed up quite reguarly offsite.

Re:Confused

[PunchSix]

Was the code that was stolen then deleted by the thief?

That would be awful! The stolen code would be distributed to millions and Valve would have no way of getting that widely distributed code back!!!

Re:Confused

[Auckerman]

"Why would this cause any sort of delay?"

One possible explaination is that the network code will need to be made incompatible to prevent cheaters. APIs may need to me moved around and renamed to prevent see though wall cheaters. Stuff in the code may need to be hidden to make it harder for cheaters to mod the dlls.

Just a guess....

Re:Likely a change to stop "pirating".

[Blenderkitty]

Are you serious? How much money do you think Valve makes off of the sale of a game? How many MILLIONS?

Do you HONESTLY think that they would even make 1/10 of that solicting for donations from the good of one's heart?

How much money do you think cdex + xiph + bittorrent + scorched3d + blender + tons o' other donation-based projects get per year? Answer) A mere fraction of a fraction of a fraction as much as Valve does.

If you want anyone to blame

[Sir Haxalot]

It was Myg0t that got it, and Hitman, an ex-member of Myg0t, that released it.

Re:If you want anyone to blame

[Sir Haxalot]

Mod parent down. There is no evidence that supports that any member of myg0t was the hacker. They are just a bunch of assholes that will claim anything to get attention.
Until the FBI knocks on someone's door, nobody truly knows who the hacker was.
Hitman was in #halflife2 EFNet giving links to the source HOURS before anyone else had it. Enough evidence?

Noooooooooo!

[Control-Z]

Ok, it's not that bad but I'm modarately disappointed. But some of these fanboys I've been reading posts from on USENET might just kill themselves. Maybe someone should set up a crisis counciling center?

Other news: beta leaked, apparently...

[Tyreth]

There's a buzz at the moment on irc.quakenet.org #hl2-source and other places about the beta being leaked.

I would submit it as a story, but someone else probably has, and I've never had a story accepted yet :)

The NFO was on nforce.nl for a short time, but has since been removed. The leak has been confirmed here, and a few claim to have it (but they could be lying).

I've also seen a screenshot of the folders with all the map files in it, and the names look very much like what one would expect the long gameplay demo to be made from.

Not good news for valve :( I am disappointed that the game had to be delayed - and for all of you who have taken the source or download the beta, I hope you remember your duty to purchase the game when it does come out.

Re:Can you really cover up all the holes exposed?

[Viol8]

"allowing free reign for cheat coders and (most likely) unlimited cd keys... is six months really enoughtime to really fix these holes"

Err yes! 6 HOURS should be enough to come up with a new key generation algorithm! As for cheat coders, they can disassemble the executable anytime, they
don't need the source code and in fact it probably wouldn't be much help anyway. As other people have said , this is just BS to cover up more delays.

Re:Likely a change to stop "pirating".

[Anonymous Coward]

Yeah, or they could consider free copying of the games as promotion for their concerts, where they make the real money.

When will Slashdot users grow up?

Games, movies, and even songs from the Backstreet Boys cost huge amounts of money to produce. You will be charged for copies, one way or another.

If people can't figure out how to slow down this ridiculous level of IP theft pretty damn soon, I guarantee you that we will have DRM shoved down our throats. In this case already, the delay of several months is probably to put in place with is effectively DRM, in order to cut down on multiplayer cheats.

Sounds fishy

[Fnkmaster]

I'm assuming the only reason the lifting of some portion of source code would lead to a delay is if it contained their copy protection code. Otherwise, so what if somebody obtained 1/3rd of the source code? What would they do with that, other than perhaps guide them a bit in disassembling the finished executable, assuming they could figure out what was what. If their copy protection system was sufficiently robust, they should be able to get around a compromise of that with a few changes - it shouldn't require months. But then again, if you assume even a moderate number of changes need to be made, the re-testing and repeat QA work required could take a fair amount of time.

Still, it sounds more like this is a convenient excuse for late delivery to me. I'm sure this guys email really was compromised, and hey, it sounds good to the uninitiated - "our code was 'stolen', we have to go rewrite a lot of it, we'll be delayed by a few months".

Parts that will need rewriting

[Builder]

There are a lot of posts asking why the delay and why does it need rewriting. I would guess that the majority of the game WON'T need to be recoded, but certain things like CD key auth code will, certain networking code, etc.

4 months to do what, exactly?

[Ndr_Amigo]

Four months to rewrite what exactly? Apart from possible Steam issues, for which I can't see four months solving any more than two weeks, there is (allegedly) nothing in the actual game source worth changing. Let's outline what will probably be done, to what should really NEED to be done:

* A week or so to fiddle with Steam and break compatibility enough to prevent the leaked source being of any use. Although, as it is supposibly a secure content distribution system, I do not see how the source floating around would hurt it. But then again, HL2's "Source" engine was supposed to be all new, but in reality it's (allegedly) still based off of Quake1/the original HL1 codebase.

* A few days to change some APIs to prevent engines compiled against the leaked code from running the release game DLLs. Again, this shouldn't really be needed - the server should be anti-cheat enough to catch abnormal physics behavior (eg, no walk/shoot-through walls, Neo style flying blah blah), and optimised enough not to send entitiy data for players/objects not REALLY in the players view (eg, no see-through-walls cheat)

* Another few days to similarly break the network protocol. This is easy enough to do ACCIDENTLY when coding engines, so... :)

In reality, nothing SHOULD need to change... and the only things worth changing should only take a short amount of time and only be in the form of obscurification and not be subject to the need for extensive re-testing.

Ah well.

Re:Can't blame anyone but themselves...

[Karhgath]

He wasn't that stupid. The email used a old buffer overflow bug in the preview pane of Outlook to install the program, Gabe just had to click(not even open) the email for it to install the trojan.

However, it's mind-bending that their Outlook weren't patched(it's a very old exploit) and that he uses the preview pane in Outlook, on his work related computer. I know that they are backed by Microsoft, and thus probably gets all the MS toys, but they still forgot to patch them.

A shame. Still, a custom written trojan made against Valve to target their system and get the code/data of the game isn't something you see everyday. Either this kind of thing doesn't happen often, or it happens often but it's never detected(or acknowledged). Think industrial espionnage. Either way, it's not an easy to spot/cure, not antivirus/firewall can detect it effectivly if it's custom written against you. They probably probed Valve to check what exploits would or wouldn't work, so it's not as easy as to say: they should have patched, because the hacker would probably have tried another way and with a little determination, would have still compromised their systems enough to get some data.

Re:SSL

[Delphix]

Generally HL hacks intercept the DLL calls. SSL on the network connection wouldn't help at all.

This Just in

[VEGETA_GT]

Doom3 to beat Half-Life 2 to market

Now isn't this a scary messed up thought

Re:This Just in

[Patrik_AKA_RedX]

Nah, Duke Nukem Forever to beat Half-Life 2 to market.

Now that's scary.

This is why there could be a delay

[Pvt_Waldo]

It's not because the game leaked, but because the underlying systems that ensure that players can't easily cheat, warez the game, or access the personal information of other players.

Part of what was compromised was probably the code that handles CD key authentication, user online authentication, etc. So clearly warez and such for this game could be hugely rampant.

Part of what was compromized was probably the code that handles Valve's anti cheat system. So clearly the cheats that override that system could be hugely rampant.

Part of what was compromized was probably the code that is the game's engine. So clearly there could be cheat authors easily creating wall hacks, aim bots, and any number of other cheats.

Part of what was compromized was probably the code that handles purchasing the game over Steam. So clearly there could be some risk of credit card and online commerce fraud, personal information leaks, etc.

Look at it this way. The blueprints and plans for the bank got stolen. Thieves are studying them now. The bank is going over the blueprints with a fine toothed comb to fix the obvious (and not so obvious) weaknesses which are more clear when you have the plans.

Re:This is why there could be a delay

[radish]

Yeah, cos no one ever decompiles anything. Please. If your lovely CD key checking system is vulnerable to a source code release, then it's just plain broken.

Wrong

[Overly Critical Guy]

Ever heard of a little thing called Steam? All mention of CD authentication and so forth aside, Steam was supposed to be the big thing to stop cheating.

Now it's all exposed. People were going to give their credit card numbers to this thing. Now it's open for all to see and anyone can exploit/spoof it.

Yes--contrary to the Slashbot idealist mindset--there are cases where security through obscurity is the best method. You have to look at each situation inviduallly and logically (instead of covering everything with a veil of ideology).

This is nothing more than them using this as an excuse for delaying the game - something that would have happened anyway.

Yeah, it's "nothing more," oh Valve Software insider. Please. The game was ready to ship for September 30. The hack happened September 11. Guess what was announced not much longer later? That's right, the delay.

We'd already be playing this game if it wasn't for the source leak. Valve's plans were ruined. I'm hoping for late November.

Re:Wrong

[Synn]

Yes--contrary to the Slashbot idealist mindset--there are cases where security through obscurity is the best method. You have to look at each situation inviduallly and logically (instead of covering everything with a veil of ideology).

If security through obscurity was the best method here, then what would've happened if the source was leaked after the game had hit the stores?

They would've been totally screwed.

That's why security through obscurity is never the best method.

Re:Wrong

[johnnyb]

"there are cases where security through obscurity is the best method"

PLEASE don't say this. I understand what you're trying to say, and that is correct, but your wording is completely horrid.

Obscurity is just that - obscurity. Using obscurity for protection is actually a decent plan in many cases - it's just not the same thing as security. The problem with "security through obscurity" is not that people aren't protected enough, it's that they are _confusing_ security and obscurity - thinking they have security when they only have obscurity. Both offer protection, but with different expectations.

There is NO SUCH THING as security through obscurity, and those who try show a complete misunderstanding of the issues. The can be _protection_ through obscurity, but security in relation to computers has a certain, specified meaning, and when people start throwing it around in connection with obscurity, it just makes the situation a lot more confusing than it needs to be.

Re:Lame excuse

[fermion]

With an intrusion like this one can never be sure of the extent of the damage. My guess that they will

Roll back to a known secure codebase
Allow the programmers add back in code written since that date
revalidate the codebase
rewrite protocols to make the new release less vulnerable to the hacks created from the code leak
Then add in any functionality originally scheduled for this release and validate

hello, outlook

[Stinking Pig]

See the story at The Register. They link to Valve's forum, where the general manager details how the code was leaked: in short, his own account information was stolen via Outlook, then several other employees were hit with a Outlook preview-pane virus that installed a keylogger.

Of course, this is no reason to think that Outlook isn't a perfectly good solution for email. Outlook is great. There's no reason to consider any alternatives. No matter how much money you lose to Outlook virii, simply look at the silly dancing monkey!

Re:hello, outlook

[DickBreath]

I bet Slashdot wouldn't be so smug if the attacker had gotten in via the also patched SSH exploits that were out recently.

Yes we would be.

It is one thing to have a bug (i.e. buffer overflow) which can be exploited. That can happen to anyone.

It is a whole different thing to have software that is not designed with security in mind. SSH is designed to be secure. Outlook is not. IIS is not.

You're comparing a bug (which anyone can have) to a security design problem (which Microsoft seems to have plenty of).

Running a web server under the System account? Executing strange code merely by receiving e-mail? Showing spammer's links to external graphics by default? A web server that allows dot-dot-slash URL's to serve (or execute) files outside the WWWRoot directory? The people who wrote this were NOT thinking the slightest about security.

Um, yes we would still be as smug. And rightfully so.

Please, shut up

[brkello]

How many whiny posts do there need to be on: "Why did they have to delay it? This is BS". Well, here is a reason. If your company just got hacked in to and important information was stolen and leaked, instead of working on the product, you have to find what the vulnerability was, how to do damage control, how to re-structure how you do business so it doesn't happen again (i.e. redesign the network and create new security policies), and then have to get back to work on finishing the product while trying to make sure that anything cheaters would have gained from the source is fixed. I would say that is pretty large amount to do in a few months. Don't you think they would love to get it out so they can make money? Just use some freaking common sense here. If you are surprised by these delays, then you didn't think very hard. If you are upset by the delays, join the crowd, hunt the hackers, whatever. Just relax, it's a game, go buy a different one. It's not the end of the world.

There should be an investigation... of Valve.

[Lord_Pain]

I admit to being a cynic... but this stituation strikes me as being too much of a coincidence.

1. Valve is not in a very profitable place.
2. They promised the world with HL2.
3. Theft of code...

My conspiracy riddled mind tells me that they painted themselves into a corner with a brand of paint called Daikatana... and they need money.
So they arrange the "theft" of their source code. This gives them an excuse to delay release and avoid bad press. Perhaps they can claim insurance for the theft? This way they kill two birds with one stone.

Of course this is just baseless speculation on my part! Cheers!

HL2 Not delayed?

[slycrel]

Check this out: http://www.halflifesource.com/ These guys sound like they'll have the real scoop one way or the other here shortly.

Delay not confirmed

[bios10h]

Vivendi Universal Says Delay Not Confirmed
Tuesday, October 7, 2003
According to a news article posted today on a UK press release, there is a Half-Life 2 delay. We already know that Valve does is not mentioning a delay.

We received an email from Mike Thompson who says he works for Vivendi Universal and writes:

quote: "delay is not confirmed..."

Here we go around and around... again...

From Half-Life Source Dot Com

Re:Likely a change to stop "pirating".

[Synn]

When will Slashdot users grow up?

When people realize that when one slashdot user speaks, he doesn't speak for all slashdot users.

Re:Uninformed

[Oddly_Drac]

"Well, before you start blasting Valve, why don't you actually read up on the hack? It was a buffer overflow in the Outlook preview pane that allowed the hacker to install custom versions of RemoteAnywhere."

Alledgedly.

And when was that exploit patched in Outlook Express?

I think it's perfectly justifiable to have a giggle at Valve because that's the kind of schoolboy error that companies are not supposed to fall victim to, especially software companies.

Re:My HL2 Conspiracy Theory

[PainKilleR-CE]

Since VU is operating at a substantial lost, they are prime to be saved by Bill Gate's wallet. Since Half Life2 [neoseeker.com] and Xbox2 [arstechnica.com] are both optimized to run on ATI's hardware, I can see the Richmond's Borg needing their killer app for XBOX2. Gates says "Hmmmm, Half Life2 sounds good. Buy them out boys!"

One big problem:
VU doesn't own Valve. VU owns Sierra, and Sierra is the publisher for Half-Life (and currently for HL2), but Valve owns Half-Life 2 and is self-funded. Gabe Newell formed Valve with his own money (gotten from being a well-payed Microsoft employee) and funded Half-Life without Sierra's (or VU) help. This is why Valve was able to delay Half-Life for a year in the first place. This is why Valve can push back HL2 without VU forcing it out when VU is operating at a loss. VU has no say in when the game is released unless their own QA finds problems with the final code and sends it back to Valve for more work (in other words, Sierra can delay HL2, but they can't force it to be released early).

Microsoft could probably buy Valve if they wanted HL2 bad enough, but I think it would be more than it's worth, since Valve is privately owned, self-funded, and making money hand over fist off the best-selling FPS of all time.

TODO HACKHACKHACK

[Leffe]

There are a lot of TODOs and HACKHACKs in all Quake-derived code, even the Quake 'SDK' probably has a couple of them left. It's some kind of design style I think. At least it's not a bad one as it highlights the areas that are not really finished(not that anyone will ever fix it though, they are more like - I want this, someone do it for me?).

If you grep through the official Half-Life SDK you'll find at least 50 TODOs and HACKHACKs. (Much more than that probably, but I'm playing safe.)

Re:Likely a change to stop "pirating".

[godders]

When people realize that when one slashdot user speaks, he doesn't speak for all slashdot users.

April 2004

Re:*This* is "Slashdot", isn't it?

[ivan256]

Slashdot isn't populated by 400,000 clones of Richard Stallman. Many of us are sane people. It is quite possible for people to read slashdot and write closed source code. I personally, for example, feel that there is a place for open code, and a place for closed code. Neither option is the correct choice for all situations.

I am surprised, however, that none of the security gurus that post here on a regular basis have commented on the fact that had the game been written correctly and securely, even to source wouldn't have assisted cheaters, and this delay could have been avoided. That is, of course, if you believe the leak was really the cause of the delay and not just an excuse to mask that they're not really done yet.

One last thing:

And are they not going to charge the public money to buy a license for said game?

The game engine itself is worthless to the average game consumer. They make their money on retail licenses of the data. The reason they have a closed source game engine is so they can license it to other developers. If they were only aiming for retail revenue, an open source engine would have been a perfectly valid option.

Re:This is stupid

[coolgeek]

You know the Duke Nukem developers are kicking themselves, saying "Why didn't we think of that."

This is not good

[failedlogic]

Valve is legitimately trying to protect their IP and if takes them until April to recode some parts of it then so be it. Gabe said its taken at least 30 people 5 years to code the game. Hopefully, Valve doesn't go broke because of this.

To have a trojaned e-mail sent to Gabe's computer is somewhat to be expected. I'm sure script kiddies have also tried similar things on Microsoft computers, etc. It was stupid to actually have any of the computer(s) with the source code connected on the Internet. If they have the budget to run w/o release for 5 years they have the money to buy a few extra computers for Internet use ONLY.

I think its kind of ironic though. Valve is acceptably asking that everyone respect their IP and remove links to and delete stolen source code. Everyone but the script kiddies and hax0rs will comply. But if you try and take credit for a script kiddies' work they'll whine and complain to no end.

TCO

[bl8n8r]

There's a TCO argument if I ever heard one.

Not with regard to FPS's

[Myrv]

In your online poker example you can have a central trusted server that insures that nobody is cheating (at least technically).

There is no way to do that with FPS's (not yet at least). The amount of info that would be needed to be passed between the client and the server in FPS games would be cripling if you expected the server to be the final arbitrator of all actions.

The only way FPS games can maintain the required speed is by offloading the majority of processing to the individual clients. In order to do this you have to trust the client. One of the key ways to trust the client is to obfuscate it. Not perfect, but at least it's one level more of protection than you would have if somebody has your source.

Really, the only way to protect the code is to build in some kind of self sanity check (i.e. return some kind of checksum to the server which verifies the client). This is only as good as the verification routine though. Once the method of verification is determined you're back to square one. You can improve upon this by constantly supplying new verification code to the client but it still comes down to security through obscurity.

When you need to trust your client but you don't have control over it this is about all you can do.

Re:This is stupid

[Anonymous Coward]

Because they'd need actual source to leak? :-)

Re:Likely a change to stop "pirating".

[Lordrashmi]

But could they have made such a great mod without having something to start with? I don't think so. How many from scratch, free, quality games do you see?

Re:Likely a change to stop "pirating".

[Lordrashmi]

I had never heard of those games but I googled for them. They look interesting and I will try atleast bzflag as soon as I finished my latest game (halo on the PC...which isn't nearly as good as XBOX'rs said it was). However, I don't think those can compare to HL, CS or HL2.

You can have a network without "the internet"...

[Shalome]

There IS such a thing as an intranet that is physically separated from the internet.. internal servers completely inaccessable from the commercial 'net.. KVM switches so all machines are accessable from one workstation.. completely internal secure shell, telnet, ftp, whatever. A setup like that is totally realistic and desirable for a production and/or testbed environment.

Of course, this eliminates the ability of a coder to work from home or do things like surf the internet and check e-mail from the same box they code on.. But if you don't want your code leaked, don't put it on a box that's in any accessable from the commercial internet.

Re:Uninformed

[bryhhh]

I know that Valve aren't the greatest where security is concerned, But if you ask me, it serves them right for having such insecure systems.

I like many others have pre-ordered half-life2, but I'm seriously considering cancelling my order. If they can't grasp basic security proceedures, they don't deserve to be successful.

I love to know why a source code leak cost them four months? I could understand it if they lost a portion of the code.

Re:Huh??

[canajin56]

I think he was saying that they have to halt everything for 4+ months because if somebody has seen the source, they can cheat. But with a game, that is somewhat understandable. Somebody can change their executable to, say, aim automatically, or draw all of the walls 75% transparent, or something. It's not like a ftp daemon, where just because they see the source doesn't mean they can hack a server.

There is NO way to prevent that. How would you do it? Checksum on the executable they are running? They could send you whatever value they want. Have a seperate app that checksums both files? That is how current anti-cheat systems work. They are pretty good, but not 100%. The only way to get the people with the source at about the same cheating-ability-level would be to change the protocols so they would have to do some work to actually get it to connect. And change the file formats so it won't be able to load the game maps without some work, either. And they can't be minor changes, because the less work the changes were, the less work the hackers have to do to make the same changes.

The piracy thing isn't as much of an issue. Sure, a pirated version will run single player, which is a good game in of itself (Judging by the first one.) But it won't play online. With a few changes, this could be extended to the single player game as well. When you install, it tells Valve your CD key and registers you. Whenever you play single player, it tells Valve that you are playing. Sure, you could play single player if you disconnect your internet (Because it would SUCK if you MADE them so they had to connect for single player) but how many people would be willing to do that? And as for being able to change the binary so that it doesn't check for the cd....Half-Life doesn't check for the CD.

On the other hand, STEAM shouldn't be compromized because somebody saw the source! It isn't like a game, it's like FTP. Seeing code for the client shouldn't let you download whatever you want. If they do ANY authorization at the client, its their own damn fault. NEVER TRUST THE CLIENT.

Oops, I didn't say "Security though obscurity" once :O

How about this donation model?

[Ohreally_factor]

It's already in place and seems to function.

It's called paying for the damn game.

Re:New theory: code was not leaked, just a lie

[Enucite]

having to rewrite the part that was lost

You do know that when people say "stolen" now they just mean "illegally copied". Valve still has all the code.

And just for clarification, the "part that was lost" is the entire source tree for Half-Life 2, Counter-Strike, Team Fortress 2, Steam, and all the dev-tools/utilities (map editor, 3dsmax plugins, etc). Which would probably take them another 5 years to rewrite if they chose to take that route. ;)

it really was myg0t that did it -- some logs

[Fo0eY]

chat log of myg0t member talking about hacking valve and stealing the code

http://gtwy.hl2arena.com/big_log.txt

and an email myg0t "recieved" that was sent internally at valve
remember, valve was hacked using an outlook virus and gabe talked about them knowing people where in his email

http://www.myg0t.com/ChrisNewcombe-PR.txt

bullshit.

[twitter]

It's not because the game leaked, but because the underlying systems that ensure that players can't easily cheat, warez the game, or access the personal information of other players.

Next you will tell me that XP is so full of holes because someone "stole" it's source code before M$ sold it to China and the former KGB. That's almost as good as them swearing that revealing the source code to Windoze would be a national security disaster. Give me a break, will you?

Warez only needs to hack a binary copy.

Cheats only need to watch their traffic.

None of this makes a difference if the system is well made to begin with. This is why OpenSSH is a secure system despite open publication of it's source code.

This is just more anti-open and anti-free FUD. Shame on VU for using Outlook and M$ for anything they wanted to keep to themselves. Shame on them for blaming software and the philosophy behind it for their own failures and shame on them for not being able to get their shit together. ID games rules, VU drools under Bill Gates thumb.

Re:Likely a change to stop "pirating".

[Lordrashmi]

Not to nitpick, but if he doesn't have a graphics engine, how does anything else work?

As for an engine, the source for Quake2 is released. Could he use that?