Exploit Found in Seti@Home 266
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 ;)
Linux/Solaris client is there, if you dig around (Score:5, Informative)
ftp://alien.ssl.berkeley.edu/pub/setiathome-3.08.i 686-pc-linux-gnu.tar [berkeley.edu]
[berkeley.edu]
ftp://alien.ssl.berkeley.edu/pub/setiathome-3.08.s parc-sun-solaris2.6.tar
Can't seem to find 'em on wcarchive.cdrom.com, the other mirror site -- anyone got a link?
In the wild or not? (Score:5, Informative)
- There was a potential buffer overrun in the networking code of the client that is fixed with version 3.08. Note that to exploit this vulnerability, a potential attacker would have to trick the client into contacting a fake server rather than the actual SETI@home server. To our knowledge,
- no SETI@home client has ever been attacked in this manner.
Whereas Jamie claims that- an Exploit [sic.] was found in Seti@Home and
- there is code exploiting the hole actually running about in the wild.
Can anybody help clear this up until the linked site get back online?Mirror (no pics or downloads) (Score:5, Informative)
Of Course It's Slashdotted (Score:5, Informative)
Confirmed information leaking:
This issue affects all clients.
Confirmed remote exploitable:
setiathome-3.03.i386-pc-linux-gnu-gnulibc2.1
setiathome-3.03.i686-pc-linux-gnu-gnulibc2.1
setiathome-3.03.i386-pc-linux-gnulibc1-static
setiathome-3.03.i686-pc-linux-gnulibc1-static
setiathome-3.03.i386-winnt-cmdline.exe
i386-unknown-freebsd2.2.8 (Special thanks to Niels Heinen)
SETI@home.exe (v3.07 Screensaver)
Confirmed DoS-able using buffer overflow:
The main seti@home server at shserver2.ssl.berkeley.edu
Presumed vulnerable to buffer overflow:
All other clients.
PATCHED VERSION
Are available [berkeley.edu]
BACKGROUND INFORMATION
From "http://setiathome.berkeley.edu/" :
"SETI@home is a scientific experiment that uses Internet-connected computers in the Search for Extraterrestrial Intelligence (SETI). You can participate by running a free program that downloads and analyzes radio telescope data. "
"The SETI@home program is a special kind of screensaver. Like other screensavers it starts up when you leave your computer unattended, and it shuts down as soon as you return to work. What it does in the interim is unique. While you are getting coffee, or having lunch or sleeping, your computer will be helping the Search for Extraterrestrial Intelligence by analyzing data specially captured by the world's largest radio telescope. "
"The client/screensaver is available for download only from this web page - we do not support SETI@home software obtained elsewhere. This software will upload and download data only from our data server here at Berkeley. The data server doesn't download any executable code to your computer. All in all, the screensaver is much safer than the browser you're running right now!"
There are currently over four million registered users of seti@home. Over half a million of these users are "active"; they have returned at least one result within the last four weeks.
THE VULNERABILITIES
The seti@home clients use the HTTP protocol to download new workunits, user information and to register new users. The implementation leaves two security vulnerabilities:
1) All information is send in plaintext across the network. This information includes the processor type and the operating system of the machine seti@home is running on.
2) There is a bufferoverflow in the server responds handler. Sending an overly large string followed by a newline ('\n') character to the client will trigger this overflow. This has been tested with various versions of the client. All versions are presumed to have this flaw in some form.
3) A similar buffer overflow seems to affect the main seti@home server at shserver2.ssl.berkeley.edu. It closes the connection after receiving a too large string of bytes followed by a '\n'.
THE TECHNIQUE
1) Sniffing the information exposed by the seti@home client is trivial and very usefull to a malicious person planning an attack on a network. A passive scan of machines on a network can be made using any packetsniffer to grab the information from the network.
2) All tested clients have similar buffer overflows, which allowed setting eip to an arbitrairy value which can lead to arbitrairy code execution. An attacker would have to reroute the connection the client tries to make to the seti@home webserver to a machine he or she controls. This can be done using various widely available spoofing tools. Seti@home also has the ability to use a HTTP-proxy, an attacker could also use the machine the PROXY runs on as a base for this attack. Routers can also be used as a base for this attack.
3) Exploitation of the bug in the server
Re:If you're asking people for their cycles... (Score:3, Informative)
Why don't you release the source code?
We decided not to make source code available for security reasons and for science reasons as well. We have to have everyone do the exact same analysis, or we can't have any control over our research and be confident in our results. We were also worried that there may be a few people that want to deliberately try to screw up our database and server.
Re:Is my box owned? (Score:2, Informative)
Note that to exploit this vulnerability, a potential attacker would have to trick the client into contacting a fake server rather than the actual SETI@home server. To our knowledge, no SETI@home client has ever been attacked in this manner.
So it's unlikely you're owned from this. Some general tips to check your box's health:
On linux, run `lsof -i` as root to see what kind of connections your box is listening for/has established.
On windows, run `netstat -an` to see much the same.
As always, monitor log files and bandwidth usage for suspicious activity or traffic spikes you didn't initiate.
Re:Folding@home (Score:3, Informative)
They may or may not have similar vulnerabilities, but since none are open source, there's no way for us to know. All the same, I wouldn't worry about Folding or Genome any more because of the seti exploit. I'm still genoming.
Re:In the wild or not? (Score:2, Informative)
ie, you could only do it on a local net.. however i guess pretty many people are running seti in the doorms around me..
Re:Less wastefull (Score:3, Informative)
I just hate the people who go around saying "Your distributed computing project sucks! You should run instead!". Why don't you run whatever you want to run, and let others run whatever they want to run? Sounds reasonlable? That's what I thought. Now: Shut the fuck up.
timeline (Score:5, Informative)
This advisory came 4 months late. While I'm glad this person contacted Seti first before releasing the advisory, I cannot believe that it took them two months to fix a bufer overflow! While seti@home isn't a mission critical app, I would think the seti people would want to release a new version very quickly, at the very least so that they know that their personal omputers can't get exploited.
Bah, forgot about a username.
Re:Ever reuse code? (Score:5, Informative)
I suppose if it's documented to only work in certain cases, that's acceptable, however, the the code that calls it without checking for the input is then broken, and buggy. It should be fixed. If it can't be checked before calling the functionality, then the functionality better work for all inputs. That's good software. Stuff that just assumes that unsafe input will never, ever be put in, is a bug. A security hole. It's not reusable code. Reusable code, checks inputs. Reusable code fails gracefully. Reusable code, returns error codes indicating invalid inputs. Reusable code doesn't have security flaws in it.
Distributing code that won't handle all input cases for use in a public distributed computing project for the sake of speed is irresponsible, and stupid. Now, I'm a lot more likely to just never run one of the distributed projects then to risk security flaws if they are willing to sacrifice security for their speed. Security should be the winning factor in all concerns when writting software. When trading security for speed, is an option don't take it. Security or ease of use, take security. Security or correctness, re-write the software using a new protocol, or new algorithm, but still take security and document the correctness flaw. Right now I only run them on machines that don't have any valuable information on them, but I'd prefer they not be used in a DDos, so it'll probably get stripped off all my machines.
Re:Linux/Solaris client is there, if you dig aroun (Score:4, Informative)
When I checked, the only 3.08 versions available were the GUI versions for Windows and Mac OS 9 (not OS X), and the two command line versions mentioned above (x86 Linux and Sparc Solaris). The ones I personally care about, the command line versions for WinNT and OS X, were not there yet.
Re:In the wild or not? (Score:4, Informative)
Jamie states exploit code exists and is in the hands of people who are not guaranteed to be friendly. SETI states that there are difficulties in exploiting the bug and they know of no clients that have been compromised. Sounds to me like someone has written and distributed the code but has not actually been able to use it.
There is no contradiction. Jamie doesn't say clients have been exploited; SETI doesn't say there's no code. Granted, reading only Jamie's statement, I'd infer that the exploit has been used at least once. Given the context of SETI's statement, however, I'd reinterpret Jamie's.
Of course, you could choose to believe that one of them is lying. I have not enough experience with either of them to make such a choice and prefer to give them the benefit of the doubt.