Slashdot Mirror
SETI@Home A Security Threat, Says TVA
evenprime writes: "Richard Chambers, the Inspector General of the Tennessee Valley Authority, has declared that employee use of SETI@Home on TVA computers
compromises computer security. I'm wondering why using SETI@Home on PCs with access to the internet would be a problem. As cheap as PCs are, you'd think that TVA would have separate internet/email PCs on every desktop, and so no form of malware could
affect their machines used for power generation and/or managment."
Even SETI states, make sure your employer is OK with this before installing any software.
Seems very straight forward to me, security breach or not.
errr....umm...*whooosh* *whoosh* Is this thing on ?
> God, this would just be hilarious if it wasn't so pathetic.
Actually, it's real simple. SETI@home is closed source. Neither the employee running it nor TVA management has the faintest idea what it really does. Therefore the TVA can reasonably be paranoid about it.
Of course, the same logic applies equally to any other CSS software that they may be running. I think the world at large is slowly maturing to an understanding of the CSS risk, though management types will see it in "toys" like SETI@home before they see it in their precious COTS applications.
--
Sheesh, evil *and* a jerk. -- Jade
> The same goes for open source software.
[In addition to what MWright already said...]
That is correct. And in fact I habitually download pre-compiled binaries to run on my Linux system.
But remember that there is an almost zero-sum tradeoff between convenience and security. For my Linux system at home, getting 0wned would have a small cost, so I only expend a small effort preventing it. If I operated the TVA, a business, a space shuttle, or a government or military computer system, then I would invest a lot more trouble in security.
If the quoted guy doesn't want the TVA 0wned, then he needs to invest an appropriate amount of effort in making sure he doesn't let any trojan horses in the gate. If that means having his staff read code, it's a real simple calculation of the cost of reading the code vs the cost of getting 0wned. And I would estimate that the cost associated with having the TVA get 0wned is pretty darn high.
Even for my ultra-low-security home system, I don't download a precompiled binary from just anywhere. Every time I do it I make a very conscious decision of "how much do I trust this site?" vs "how much trouble would it be to go another route, such as compiling it myself?" vs "what are the consequences of getting 0wned?". Even for my ultra-low-security site, I just get the source if the only binary kit I can find is made by Joe Stranger.
As for reading the code, no, I don't audit the code for everything I run on the system. However, I'm pretty much a middle-of-the-crowd OSS user (not at all a guru), and in spite of that I do read quite a bit of code over a year's time, because I like to submit fixes and enhancements for the OSS that I use. And I know that there are thousands, probably tens of thousands, of people just like me doing the same thing. Trojans will be found, and the news will spread like wildfire on the internet. The very threat of that will inhibit trojaneers to some extent, because of the risk of getting caught, and the consequences (permanent anathema, no one ever using your software or your download site again, etc).
[Insert note here re the importance of downloading your code from a "mainstream" high-use site, to make sure your code is actually the same code that those thousands of other eyes are looking at. If you download code from Joe Stranger's Fly-by-Night FTP Site, then you may be getting a trojan that your friends aren't looking at, because you didn't get the same code.]
Using OSS doesn't guarantee security, but it seems to me that it is a creditable threat-reduction strategy. I think in the future you will start seeing critical installations like the TVA switch over to OSS as a matter of policy (or if they do stick with COTS software, they will arrange a source agreement with the vendor, and run copies that they compiled themselves to ensure that what they saw is what they really got). We have already seen several non-US governments making noises in that direction, and I think it will become a near-universal reality as the world gets used to the idea of OSS as a quality solution, and becomes aware of the security implications of "trust" vs "knowlege". You just have to look at the number of spyware vendors that got caught in the last 18 months to realize that corporate/governmental paranoia about this kind of thing is not only justified, but perhaps even a moral imperative.
As a side note, the strategy mentioned above about getting the source to CSS directly from the vendor and compiling it is probably less safe than using OSS, because the CSS vendor will never distribute its software as widely as OSS is distributed, so there will never be as many eyes looking at it. I would agree that catching a trojan due to a many-eyes approach is probabilistic, but more eyes slant the odds in your favor.
Also, a dishonest vendor could give you code with an obfuscated trojan, and give trojan-free code to all its other customers that it didn't feel any need to spy on, with the result that the only eyes actually looking at the trojanized code would be the people on your own staff that you assign to it. Bad odds there, unless you spend a lot of money paying a big staff to read code.
As the world becomes more aware of the risks of spyware and trojanized software, and more aware of the viability of OSS for many uses, institutions that absolutely must have security will start adopting OSS, even without reference to the other benefits of sharing source code. This will probably happen sooner rather than later.
The day we see a shareholder suit against a company that lost its ass due to spyware or trojanware will also be the day we start seeing a mass migration of lower-security sites, too.
In our contract-minded society I'm sure lots of suits will try vendor indemnification rather than OSS,but when you start thinking about the dollar cost you would have to assign to having the TVA 0wned by a hostile party (terrorist, extortionist, prankster with no sense of consequences, etc.), then you'll realize that vendor indemnification would be completly meaningless. Which is why I say that society needs to run its computers on "knowlege" rather than "trust". Hopefully the world's suits and lawmakers will figure this out without having to have a incident to elucidate it for them first.
Just my opinion, as always.
--
Sheesh, evil *and* a jerk. -- Jade
What they are saying, as I've said in past jobs...
1) Your computer is not your computer, it is the company's computer.
2) Your computer is to assist you in doing your job.
3) Security is important
4) So you don't run anything we don't approve of.
The security audit of a new app can be fairly simple.
Question #1: Do employees need to run this? NO. Jump to DENY
Anything running that access the network, unattended, is a *potential* security threat. running the most secure of secure ftp servers is still a threat if *you don't need one in the first place*.
>
> This sounds suspiciously like a comment from someone who has no idea what SETI@Home does, and is condemning a random program that happened to access the Internet.
1) You're right. There's probably a much greater security thread from spyware that comes with things like RealPlayer, and/or users installing stuff like AudioGalaxy or Comet Cursor, etc. on their machines.
2) He's also right. Maybe for the TVA, this is a little paranoid, but a keyword search on "covert channels" provides some insight.
Suppose you were a KGB agent assigned to find out when the TVA was most worried about blackouts. You'd be very interested in knowing when large numbers of TVA employees were working overtime at the head office.
Rather than hax0r the head office's computers (exposing yourself to risk), or have an agent staking out the head office (exposing the agent to risk), you'd just eyeball SETI@Home's publicly-accessible stats.
You could then deduce that something was FUBAR in Tennesee when "Team TVA", which was churning out one unit every 70 minutes from 5:00pm to 9:00am, dropped their stats precipitously - say, damn near nothing getting done until 11:00 pm, one unit every 120 minutes from 11:00 pm to 1:00am, and only going to the "regular" 70 minutes per unit from 1:00 am to 9:00am.
In fact, in the simplified case I've specified above, you could not only make an educated guess as to how many employees were working overtime, and for how long, you could even make an educated guess as to what hardware platform was being used by The Guy Who Stayed Until 1:00 In The Morning.
Like I said, for the TVA, this is probably paranoia. But for other agencies, information leaked by covert channels can be deadly serious.
(In business too -- at a small enough company, suppose you saw similar data patterns and you knew what CPU power the CFO's PC had. If the CFO's up all night, every night, on the last week of the quarter, maybe he's desperately trying to make up the numbers. Such information could be worth millions of dollars, and it wouldn't even be insider trading, because you're only making an educated guess based on the working hours of the CFO.)
I hate to side with an ignorant bureaucrat, but in this case, he's right. (Even if, in all likelihood, he hasn't the faintest clue as to why he's right ;-)
It also says these are `100% safe and completely free.' This program is just as dangerous as Seti@HOME could be.
TVA is right -- Seti@HOME is a risk. It's probably a small risk, but for all we know, the client could have code in it that allows Seti@HOME to take control of your box at will, for example.
It also will cause your computer to use more power, and to run slower (ok, just a tiny bit slower, but still.) All this, and it offers the company *nothing* (after all, it's not TVA's job to help SETI.)
And the boxes belong to TVA. Therefore, they're completely in their rights to ban Seti@HOME, and they're doing the right thing.
I am absolutely amazed that employers do not use the power of their idle PCs THEMSELVES!
There are so many applications out there already - SETI@home being one, others include a few at distributed.net, FightAids@Home.org, and there are others cropping up, supporting cancer research, some commercial projects, code-cracking. Many many popular (in a geeky or tear-jerky way) projects that interest us enough to donate our unused cycles.
Now, a company such as TVA - that would rather its employees does NOT use their cycles for such tasks - would do well to provide some other diversion to occupy the screens of its employees. Hey, they could even license the software from SETI, Entropia, or some other vendor of distributed computing solutions, tart it up to look nice with their logo, and plug in some of their own research models. I'm sure their scientists have some energy calculations that could benefit from massively parallel computing.
And what of the rest of the world's processors? In a large customer service department in any medium-large sized company - even one with no real scientific research needs - there will be many PCs available for many hours. It would be a simple matter for such a company to rent out its spare cycles, again using the same software, with suitable logos. Except this time it would be managed internally, with no risk of external network corruption. The information server could be housed safely with the rest of the company's servers, making a quiet buck in the background, with everyone happy.
Ah, but that would be too sensible, wouldn't it?
--
We may be human, but we're still animals.
Many CPUs have power saving capability, it's a matter of correct configuration in the bios and OS. For example, my dual Celerons (not the FCPPGA Celeron 2s, but the original PPGA) do a very nice power saving operation under Win2K with ACPI enabled in the bios. Temperatures go down significantly...nice for hot days. I stopped running RC5 for just this reason.
And that isn't a good answer? Do you expect them to analyze the Seti@home software to determine exactly what risks are involved? Do you expect them to do the same for every piece of crapware that is out there that the user "might" install on their system?
Sure, Seti@home is mentioned specifically, but it's not a problem that's specific to that code. No Sysadmin could realistically do anything but "forbid" basically all non-company-issued software, especially those that connect to the Internet.
Now, on the other hand, if a company wanted to support Seti@home specifically, it would be feasible to test it so that they could determine the risks... but that's one out of millions of programs that the user might want to install.
MadCow.
I used to have a sig, but I set it free and it never came back.