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 ;)

15 of 266 comments (clear)

  1. Re:Firings... by fadeaway · · Score: 5, Insightful

    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.

  2. Re:Firings... by kiltedtaco · · Score: 3, Insightful

    I believe he was refering to people who run SETI without their employer's permission getting fired for doing so, as it now may be more of a problem.

  3. Re:Firings... by Anonymous Coward · · Score: 2, Insightful

    I'd think the problem is more with people who installed Seti on a bunch of company machines(like desktops) to run in non business hours. Each one of these is now a security risk, and if only one is compromised - leading to other sorts of data loss - the person who allowed this policy might lose their job. The extra expense to patch such a non critical might be enough for management to say enough.

  4. Buffer Overflow stupidity by jtdubs · · Score: 4, Insightful

    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

  5. Re:That's why I only give my extra cycles to by error0x100 · · Score: 2, Insightful

    Honestly, why do people feel the need to be snobbish about how they use their spare CPU cycles?

  6. Re:Alien Fury by corvi42 · · Score: 2, Insightful

    I wonder how you'd manage such a DoS?
    I suppose you could set up hundreds of transmitters around uninhabitted star-systems that spew meaningless signals. If the alien race was running a program comparable to our SETI, they would start detecting these "false positives". The signals would look like they were meaningful, patterned signal coming from inhabitted worlds, when in fact they are meaningless rubbish ( produced say from some pseudo-random function ). This would tie up a large amount of the computing & scientific resources of the alien world trying to decode these mysterious signals. Perhaps if you created enough of these false ones you could cloud out the alien civilisations abilities to search for legitimate signals, hence effectively DoS'ing their entire world in this regard.

    It's an interesting possibility, particularly if you happened to be a reclusively civilisation that is afraid that it might be found and visited by ( potentially warlike ) alien races. You could "hide in the noise" so to speak of hundreds of such false-positives. If you were lucky, you might convince the aliens to just give up looking about in your area of the galaxy.

    Of course it's not exactly a very "friendly" thing to do, and you might just incur the wrath of aliens who would otherwise have been of a much nicer disposition.

    Another strategy that I've thought would be effective if you wanted to actually attract the attention of distant worlds, would be to set up a legitimate transmitter somewhere in the vicinity of a pulsar. Pulsars are natural beacons in space, they transmit a regular radio pulse out to the universe, and act somewhat like a lighthouse in space. Such strong natural beacons would likely be of interest to any civilisation studying the cosmos, and so setting up a transmitter nearby to one ( not so close as to be overshadowed by the pulsar, but say in a starsystem nearby ) could be a perfect strategy for having yourself found.

    --

    There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie -Noel Godin
  7. Folding@home by hoagieslapper · · Score: 2, Insightful

    Does anyone know if this exploit effects folding@home clients? I do not know if they use the same engine or if the '@Home' name is the only thing they have in common.

  8. Re:If you're asking people for their cycles... by cperciva · · Score: 3, Insightful

    Yes, that's a good answer, except that it completely ignores the facts that
    1. People have turned in fake results
    2. People have deliberately tried to screw up their database and server
    3. There are apparently security holes in the client which would have been noticed much sooner if the code was open.

  9. Re:Time to retire C by Abcd1234 · · Score: 4, Insightful

    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.

  10. lmao, gotta love it by ziplux · · Score: 1, Insightful

    If this was a microsoft hole, slashdot would be jumping all over it. "MS sucks! Look at these security holes! Waa! I'm gonna go cry about it now, even though they patch them quickly!"

    I know a lot of people hate MS, especially the slashdot/open source community. But at least be fair....why is it so egregious for MS to have a few security holes where any other company would be cut some considerable slack? Like Seti@Home for example. No piece of software is perfect, open or closed.

  11. Re:timeline by John+Hasler · · Score: 2, Insightful

    > 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!

    Shrug. Closed source: what do you expect?

    --
    Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
  12. Manager's case of "told me so!" by Chester+K · · Score: 5, Insightful

    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
  13. Public Machines by mikeage · · Score: 4, Insightful

    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?
  14. Not as bad as it might sound by eheien · · Score: 2, Insightful

    This exploit really isn't as bad as people here like to make it out to be. In order to perform this buffer overrun, you would have to trick the S@H client to connect to a different server. Short of actually breaking into the host computer of the client, I believe this would prove extremely difficult (anyone know how to do this?).

    And as was mentioned in the advisory, there has been no reported case of this actually being exploited (outside of proof of concept of course, where the discoverer changed the S@H server address in the client itself).

  15. Re:Ever reuse code? by cduffy · · Score: 2, Insightful

    pffft, that's like "optimizing a shell script.

    Don't laugh too loud.

    There's always room for optimization, particularly in terms of the algorithms used. Sure, one may lose 3x the speed due to the implementation details -- but if one gets back 10x the speed by switching to a more efficient algorithm, it's still a net win. (In particular, I recall writing a clever Python implementation of a function which outperformed a naiive C implementation by about a hundredfold).

    Further, just because bash is slower than dirt doesn't mean that's true of all shells -- ash, for instance, is much faster.

    To get back on track, btw, I'm inclined to agree with the call that code with bugs or unhandled corner cases introduced for purposes of performance, footprint or whatever should never be considered reusable unless each of those unhandled cases is reviewed before each reuse -- and only rarely even then.