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 ;)
I wonder whether aliens are exploiting this to control us /me screams and runs in fear.
ftp://alien.ssl.berkeley.edu/pub/setiathome-3.08.i 686-pc-linux-gnu.tar
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?
Carousel is a lie!
But I already run a public warez server!
the Aliens doing this. Not to worry though. I will use my I-Book to hack into their systems and upload a virus.
Why is there always an assumption that exploits=firings? If it was intentionally added, yes, but if it's an honest mistake why do heads have to roll?
Coders make mistakes. That's why they put a backspace key on keyboards.
- 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?"If you think education is expensive, try ignorance" - Derek Bok
Well, let's see here. I'm going to be reading data from an untrusted source. So, I feel it's safe to assume that this data will be no longer than, oh, let's say 100 characters. Yeah, 100. I mean, who would send more than that. That'd be crazy!
That'd be about as crazy as wasting cycles on checking the length of my input. Or, dynamically allocating buffers. Or, using safe, bounded copy/read instructions. What kind of wacko would do that! Hah!
Justin Dubs
No, the backspace is there for the users. We allow it on our keyboards because it is cheaper than having separate keyboards for programmers!
Look! Their site is down! Someone must have used this exploit to launch a Dos on them! Oh wait... damn you slashdot!
Everybody denies I am a genius--but nobody ever called me one!
at least its doing something useful... rather than just pointlessly scanning some random data with no hope of finding anything.
I'm smarter than the average bear.
over here.
"If you think education is expensive, try ignorance" - Derek Bok
running winxp on the spaceship woo -.-
This sig was cut off by the sla
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
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
Live to be Moderated
Good thing the 20 computers I'm running it on aren't even mine!
The coolest voice ever.
I went in and took a look around your system. All the files seem fine. I guess you're okay.
BTW, your sig makes perfect sense if you understand that, in C, straight numeric constants are assumed to be integers, and hence 1/2 is equal to zero. The obvious fix is to change that to 1.0/2.0. Gotta love it when people complain about non-issues...
Incidentally, Java has similar rules, it's just more verbose when warning about type mismatches and loss of precision.
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.
Only dead fish swim with the stream...
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.
This is the reason employers have problems when their employees run Seti@Home (and indeed, any unauthorized software) on their machines.
As an IT professional, you talk and talk and talk and talk trying to warn your superiors of the danger of running unnecessary network services -- why you can't just open the firewall wide up to let them use their proprietary stock-tracking application; hell, why you even have a firewall in the first place.
And then Seti@Home, the ultimate nonessential network service, comes along and validates everything you've been saying. But you're running it anyway, because it's "cool". And now your network is compromised.
Should have taken your own advice.
NO CARRIER
You can just FTP to ftp://alien.ssl.berkeley.edu/pub/ and see for yourself what's there.
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.
So... for those people who installed Seti on 100 machines at school/work, are you updating them RIGHT NOW? One guy where I am put Seti on a bunch of cluster machines because, after all, no one else is using them. I certainly hope that he's working unpaid overtime patching his (against the rules) pet project.
-- Is "Sig" copyrighted by www.sig.com?