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."
If this dweeb wants to investigate and remove the use of programs that pose potential security risks, how about starting with Explorer and Outlook. What a complete waste of time and money.
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 ?
As cheap as PCs are, you'd think that TVA would have separate internet/email PCs on every desktop
Sure, why not? It's only our tax dollars...
---------------------------------------------
Recursive: Adj. See Recursive.
Not only where they breaching security, they were stealing from their employer. Idle CPU time is not free, when SETI is running the CPU can't shutdown into low power mode...
(1) You are absolutely right and don't need me to explain why.
Also,
(2) You are completely wrong and I'm about to tell you why. My job is to GUARANTEE to a group of $250/hr attorneys that their computers will work when they want to use them. I am paid good money to see to it that they don't break. One of the limitations of my job is that I don't have the time to make you happy. Sorry, I really am, because I understand completely, but I cannot risk anything, and I don't have the time to analyze everything. You don't have to agree that I'm right, but at least try to understand. See, the thing of it is that it's not my job to guarantee that YOU can do whatever you want with your computer, but that the bosses can do whatever THEY want with their computers. YOU won't fire me if I don't let you download WebShots, but when you download a screensaver that was uploaded to a silently cracked web site by evil hackers and which transferred the contents of C:\My Documents\ to (insert cracker URL here), resulting in massive litigation against the firm for violation of attorney-client privilege, THEN I'm going to get fired.
You do the math.
> 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*.
It may seem odd to those who have never had to administrate a network, but the TVA happens to be absolutely correct.
It's not SETI software in particular that is a problem; it's having your users downloading random, useless software from the internet and running it on company (and likely priveleged) machines.
Every time that program starts running, it can do whatever it wants. It could be detecting aliens in the vicinity of Betelgeuse or it could be streaming your password file the SETI server so that it can pass it around for decryption. You can't tell; you didn't compile it...you don't even have the source. Even if you did, the admins don't have time to check the code just so you can have a pretty E.T. phonin' screensaver.
"But we trust SETI", you say. Why? You can't speak personally for the competence and/or ethics of the SETI programmers. If you could, you still wouldn't be able to tell if the binary had been modified after it left their hands. The program is also executing around arbitrary data downloaded from the internet...could it be made to misbehave with bad data from a man-in-the-middle? I dunno.
Maybe all of that seems unlikely, but this is the same policy that guards against the Marketing department's "Dog of the day" screensavers and Trojan Horse emails. As recently evidenced, it's true that you can have backdoors in production software, but at least there's a business return in exchange for the risk.
It's too easy to scoff at this as "employers not understanding" when you don't understand big picture.
Odd you mention that because that's exactly what I do. I'm the Network & Systems Manager at one of the 6 Regents universities here in the State of Kansas, which will remain nameless. I also recommend distributed.net and SETI to the users of this university and have a lab cracking on the RC5 challenge. Source? What do we care about source? Better put, are we allowed to care about the security problems found in the source of the software our users download? No. We're a university. We don't have that luxury. If we as a 4-year university could say what you can and can't install for security reasons, the first things to go would be Outlook, IE, Irix, and Windows. Do we trust MSN Messanger? AIM? ICQ? What about all the various IRC clients? MUDs? Local sploits should always be a concern? Can we say what our users can and can't install? Not a chance in hell. As a net & sysadmin you have to remember one thing. Never trust your own network. Period.
Given my placement in the arena you think I'm not in, I can very easily and with great authority comment on "employers not understanding" small parts of the big picture.
--
A DMZ is also a must. The larger the network the more grand it becomes. DMZ != demilitarized either. If anything it's just as secure as you local server farm, if not more secure. You just allow services from the outside to that subnet that you don't want to allow elsewhere. Once you separate your public services (DNS, SMTP relay, www) from you local services (LDAP, RADIUS, HEC machines, etc..) you can then isolate the local services and beef up security even more internally. I wouldn't say to separate the desktop and server networks although that really what you are doing in a way. In my ideal network, each building is a 3 subnets, 1 public and 2 private. The public is general use for all faculty/staff. One of the private is for our networking hardware (non-packet rewriting things like switches, wireless access points, and repeaters). The other private is broken down more for printers, labs, special machines that only need local access, etc.. Each building is an entity. Each entity is multiple subnets. Each entity is also an interface on a core router (or trunked interfaces if need be). The server farm is also an entity independent of the building it resides in. The same goes for the administrative workstations. That's an entity as well. Each entity becomes a subnet or more and an interface on the/a core router(s). Firewalling from that point on is a breeze because of the ease of which identifying nodes on a subnet has become. The entire subnet is DMZ. This subnet is dorms. This subnet is administrative workstations/personal servers. This subnet is all server farm. Breaking it down from there and applying rules just got a lot easier. :-) Now you can identify users and types of users by subnets and actual physical interfaces (even VLANs if you want to get even more fine grained). The physical distinction makes it a breeze to place the dorms behind a Packeteer or the like.
I also contract admin at my old ISP. At that place I get very anal about my host-based security. In fact all of my machines at all my places of employment and home utilize host-based packet filtering on top of heavily TCP wrapped services. Everything is up-to-date and everything is configured with security in each daemons config file. The TCP wrappers are basically a backup for my ipchains filtering . Redundancy never hurt anyone. Beyond my server farms sit a Linux Router/Firewall. That box provides even more protection. Box A is our web server and does nothing but HTTP, FTP, and SSH) so that's all you can connect to. Box B provides no external services so you can't see squat on it. Host C is a RADIUS machine. Only local subnets have access to it and more specifically only terminal servers. Being very anal about security can be a good and bad thing. Some people are so anal that they won't allow you to SSH in to your desktop machine from home. That's unreasonably anal. I'm anal enough to prohibit RPC, Netbios, direct SMTP (as in server running on desktop machine, and DNS from home to a work machine. That's much more reasonable. The anal retentive firewalling has gotten me one very good thing. I've never been hacked. Not yet anyhow. It will happen; that's garunteed. It just hasn't happened yet. I like to think that some of my measures have helped. If they haven't, it's sure been fun learning how to do what I do. Cheers
PS==> Switching switching switching....
--
THEY just don't want you to know what sort of traffic is REALLY moving between the TVA and the Greys.
TVA=MIB?!?!
Marc Siry || interactive media professional, motorcycle enthusiast ||
Yep....it makes me wonder just how concerned they are about security if people have been running SETI for over a year before they discovered it. Why didn't they find the application sooner? Why didn't they see the processes running sooner? Why didn't they notice the freakin' traffic to and from berkeley.edu?
The security risk here isn't SETI, but rather TVA's seeming inability to notice violations of their security policies. Maybe I can pick up a Y2K surplus generator on the cheap, since now that we know how much attention they pay to their network, it's going to be a big cracking target...
>
> 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.
There might be a legitimate reason for keeping SETI@Home (or any random application) off of a major organization's computers. Go look at this issue of Risks digest. The problem described here is not a security issue, but a feature of the SETI software that can cause a few copies of it to wedge a net connection if it can't reliably get to its server.
To a Lisp hacker, XML is S-expressions in drag.
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.
Power consumption: TVA is very sensitive to this issue, though it seems some posters do not know this (what a shock!). TVA has many, many employees, and the power they use is not free (has anyone been following the California power crisis press coverage?). Every extra watt that TVA burns because some dufus won't let his screen go to DPMS suspend/off mode is potentially just more nuclear waste to be dealt with.
I believe calling SETI a risk is going a bit far, and I also don't believe that is their point. The point is about the user's behavior. Installing unauthorized software on their computer systems _is_ a risk.
cat
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?
No, it isn't a good answer. The statements imply a significant amount of risk based on running Seti@Home. Technically, they're correct. Risk is a non-zero number in this case. HOWEVER, that doesn't mean that it also isn't a trivial number, something in the range of 10^-4 or more. Given the current data set (0 security breaches in 2 million users), it's more in the 10^-6 or -7 range _at worst_. So we're talking something over 4 orders of magnitude difference from what they've decided to imply.
Now, speaking as the owner of a company, I can understand what they're doing, and the policy statement behind the "why". But they _damn_ well better go sanitize the rest of the TVA for unauthorized software (that cutesy screen saver someone bought, or the bootleg copy of Photoshop your graphic artist is using to maintain your marcomm because you're too stingy to buy a license), or they're going to look like a really hypocritical mob. Just my two cents.
Just leave the "power users" to fend for themselves. The policy I adhere to is that if you don't screw up your working environment, don't ask me to fix your machine, and don't piss off your coworkers, you can do whatever you darn well please with your office PC. If I have to mess with it, however, things change immediately for the worse. This tends to separate the real "power users" from the wannabes.
CEE5210S The signal SIGHUP was received.
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.
While TVa may seem draconian, as a government agency, they're bound by a whole lot of rules and laws, as well as negotiated labor contracts. If they let people install some unapproved programs, they'll have a lot harder time dealing with someone who really screws up. Yes, you can argue that SETI is low risk, but the point is either they enforce their rules or lose the ability to enforce them. It may not be what /.'s want, but then that's the government for you.
I'm a consultant - I convert gibberish into cash-flow.