Exploit Found in Seti@Home

Jamie noted that an Exploit was found in Seti@Home and there is code exploiting the hole actually running about in the wild. Patches are available for those of you not interested in running a public warez server or DoS client ;)

Offtopic but out of curiosity

[Timesprout]

Are many individuals (on their own machines and not he company hardware) actually running the SETI client? I started it back in 1999 but gave up when I discovered that it took about 24hrs to process one unit on my 366 Toshiba laptop making it rather unlikely that at that rate I would live long enough to find anything. To be honest I had pretty much forgotten about the project altogether.

Is my box owned?

[bcrowell]

Can anyone give any practical advice on how to figure out if your own system has been compromised? No, I don't have any tripwires installed :-(

Re:Time to retire C

[corvi42]

There is nothing wrong with languages such as C, you just have to be aware of what you're doing. Good, safe, secure and efficient code is generated by educated programmers who are aware of what they're doing. You can't replace that with any computer generated stuff. Perhaps you'll be able to patch one security hole with something like this, but others will go unnoticed. The only solution is to make sure that coders are aware of what they're doing. IMHO languages that do more for you automatically create a sense of false security in that you assume that you can let the compiler / interpreter worry about what you should be thinking about yourself. It acts as a crutch for good programming habits, and so actually encourages sloppy programming. I think this is the opposite of what is needed for secure code.

Re:If you're asking people for their cycles...

[budgenator]

That would seem to be a reasonable request but if fulfilled, it would lead to people using the source code and applying the own optimizations to it. Many people view Seti@home in a compeatative way; there have been contests, and people have cheated by saving a work-unit that was all but done and repetativly re-processed and submitted it to artificialy inflate there stats or win.

The problem is Seti@home is science, and a primary requirement for science is that results must be repetable. If I were for example to recompile to program for athlon optimisation, it probably wouldn't be too big a deal and might gain me an advantage of of 20 min to an hour for each work-unit, which are averaging about 27 hours on my older machine. Sooner or later somebody is going to take apart the program and start change the math involved which would increase the advantage but absolutly kill reproducability.

I think that this exploit would be pretty hard to exploit because you would have to intercept the IP address of the seti@home server, and redirect to a malicious server to exploit it. It would be easier to just exploit one of the many other easier to exploit security holes out there.

Re: 366 Toshiba synchronicity

[TeknoHog]

This is pretty awesome. I too started S@H in 1999 on a 366MHz Toshiba laptop (Satellite 2060CDS, K6-II), which was also my first Linux machine. I managed to crunch about 200 workunits until I got tired of the fan noise. It's worse than any desktop fan or HD noise.

In addition, I noted how the S@H team seemed to neglect optimizing the client, so I got into other projects. S@H sucks particularly on the K6. My P2-350 runs it over twice as fast as the K6-2 of similar MHz, partly because it can use the 686 optimized version.

I still prefer S@H over things like distributed.net; the latter poses purely mathematical problems, which IMHO should not be bruteforced. The RC5 crack is plain silly, and the OGR is something that might be 'solved' by other means some day. In addition, things like protein folding could use a proper theory, as you can only bruteforce individual cases. But there's no scientific shortcut in SETI, you just have to keep looking.

Re:Time to retire C

[Anonymous Coward]

Actually, I think he has a point. There are too many "programmers" out there who think that writing obscure code in C is somehow macho. It's not - it's geeky, and damn geeky, too - and not in a "good" way, but in a pocket-protector kind of way. While you can do some truly funky stuff in C, and that in turn is useful if you're writing Doom 3, how much of it is really necessary when you are coding a backend for an RDBMS?

As someone else points out, careful programmers catch their mistakes in C. Unfortunately, most programmers aren't careful. So we can either institute an apprenticeship system for programmer wanna-bes, or do the cheap and less political thing, and use better tools for the job. C is just a tool, and it's not always the best. I write in C, and Pascal (well, Delphi/Kylix these days), and COBOL, and Perl, and sometimes even Visual Basic if I need to knock off some proof-of-concept prototype in Windows. I've worked in Java, C++, four or five statistical languages, several variations of assembler and machine language, and dabbled in Ada, Turing, APL, Fortran, and several scripting languages. And when I go to write a new program, my first instinct is not to fire up GCC. Too many people do, though, and that's why we get crap programs that do stupid things like allow buffer overruns.