Slashdot Mirror
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 ;)
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.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
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 :-(
Find free books.
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.
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie -Noel Godin
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.
Apocalypse Cancelled, Sorry, No Ticket Refunds
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.
Escher was the first MC and Giger invented the HR department.
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.