Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hmm, fork-bombing... those of us who pay any attention at all to security have already read the article. You'll note it is a Denial of Service attack (not a virus or anything like that... it is annoying as hell but not the end of the world and nothing will be lost on the system when it is brought back up -- hopefully with reasonable limits defined). Many systems are not affected by this (mine for example... BSDs out of the box... Debian... and others).
It is good that you can cut and paste... at least it shows you are reading other threads here. "Local Privilege Escalation Vulnerability" these are the keywords we want to look for because this is the issue of gaining root access. I see a VMWare problem which falls in that area, an SMP problem, and most importantly a Uselib() problem. I say most importantly because it is unlikely that VMWare is on a high percentage of machines which makes it an unlikely vector. Of course, if you had VMWare than you should fix that problem. The SMP problem is also minor... it only concerns systems which are SMP -- so the admin knows to fix the problem because of their hardware setup.
The Uselib() one is a little more tricky because you need to either patch it right away... or ensure that none of the programs on your system can use that call. Best to patch it right away but it would be the biggest risk factor.
I'm glad to see we are actually talking about security problems. Now, please explain your comments in 3a. We are still waiting.
Re: Home Linux users as vulnerable as Windows Users.
Quote:
Originally posted by penguinlnx
The point is, Most Linux newbies install it right out of the box,
and haven't a clue how to tighten it down to the security level
of a server that's been running for 3 years. [[ Please note: I need you to prove that the default setup here is as bad as Windows, not that the majority of users don't change their setup -- which is likely to be true. ]]
A Linux New User would be lucky to even put together a shakey grasp
of security issues over a one or two year period, by which time
he could have been hacked a few hundred times.
Most Home Linux users don't have friends who happen to be
Server Administrators or Linux Security Experts, willing to come over for a few days.
Most current Distro kernels have their buns in the air as we speak.
Ooh... more FUD that we are going to want you to back up. "Home Linux users as vulnerable as Windows Users." This statement in particular. But everything in bold would be nice.
If you want to know how safe Nuclear plants are, read this:
International Concern:
Last year the United Nations' International Atomic Energy Agency (IAEA) warned of growing international concern about the potential for cyber attacks against nuclear facilities, and said it was finalizing new security guidelines of its own. No successful targeted attacks against plants have been publicly reported, but in 2003 the Slammer worm penetrated a private computer network at Ohio's idled Davis-Besse nuclear plant and disabled a safety monitoring system for nearly five hours. The worm entered the plant network through an interconnected contractor's network, bypassing Davis-Besse's firewall.
The NRC draft advises against such interconnections. It also urges vendors to add additional security to their software development process, as a bulwark against saboteurs writing backdoors into the code, or implanting logic bombs programmed to shut down a safety system at a particular time.
But securing the software from its own developers "would not be practical to implement," according to comments filed by Virginia-based energy company Dominion, one of two plant operators who chimed in on the proposal. "Access of the programmer to the software is a matter of trust."
Dominion also takes exception to NRC's preference against interconnection. "Remote access to safety system data from outside the physical plant is not necessarily a potential vulnerability," the company wrote. "Access to data through one-way or fixed function gateways should be allowed, assuming proper verification of the integrity of the gateway is verified."
Dominion operates the Millstone nuclear plant in Connecticut, and two plants in Virginia.
Nebraska's Omaha Public Power District (OPPD), which operates the Fort Calhoun nuclear plant, took issue with the proposal's emphasis on technological access control solutions. Obliging plant operators to protect systems with a combination of passwords, smart cards and biometrics could create more problems than it solves, the company wrote.
"Requiring additional security features could compromise the integrity of the safety system itself," wrote the company. "It is OPPD's position that a Safety System Security Plan that includes network security and has well-defined roles and responsibilities of the staff organization is more beneficial than adding unnecessary complexity to the safety system."
Though they suggested changes, neither utility opposed the plan entirely. If the measure is approved, adherence to the new guidelines would be strictly voluntary for operators of the 103 nuclear reactors already running in the U.S.
Take the following notes:
(1) Nuclear Safety computers are often accessible remotely.
(2) A Nuclear system was hacked recently, and no, it wasn't some administrator's desktop: the safety system was shut down for 5 hours!
(3) The companies don't want any outside interference or safety codes imposed. "Everything's fine, and if you mess with us you'll wreck things..."
(4) The people in charge of all this are completely insane.
Last edited by penguinlnx; 03-21-2005 at 05:31 PM.
Wrong, it may only take one weak point to get in but it is also an odds game. 3:50 odds are strongly in favor of Linux being a safer distribution. Even if there was an even mix of Linux and Windows machines on the Internet... having only about 6% of the weak points as the opponent would make you a much less attractive target.
That is also logic. But what you have failed to show is that most distributions are setup in a weak position in their default install. Which ports are usually left open? What types of vulnerabilities can we expect to find on those ports (and what are the odds the vulnerability is active)?
You have a long way to go, young grasshopper, before you approach anything near a valid point. But keep trying... it amuses me. So, anyway, I am serious... pick five distributions, tell me what ports and programs are open/running by default -- their versions and their weaknesses.
..and I'll stand by (3a). Just don't keep posting more copies of it for purposes of ridicule okay?
...Now if I *was* a cracker using Linux, or even a whole covert organization full of them with secret handshakes and gay rituals and all, and I wanted to divert attention away from my own operations,
I'd have plenty of weak, 'semi-successful' hacks taking place on my own systems, to show
that the *real* crackers were attacking me too, so I can't be a suspect...
Are the attacks on Linux insignificant because Linux is 'hackproof'?
Or is it just 'friendly-fire' testing before launching offensives?
How would Sherlock Holmes interpret the ambiguous evidence of Linux 'hacking'?
Originally posted by penguinlnx Having it Both Ways:
First you chide me for not posting info on vulnerability, especially on Nuclear Power systems,
Now, its 'flotsam' give it up.
No, no, no. I never asked for information on Nuclear Power. Stop playing the victim because you aren't. I stated that Nuclear Control systems were not running Linux (1) and were not networked (2). What you have posted supports point 1 as the Slammer worm hit Windows machines. And it doesn't contradict point 2, as the control systems are not the monitoring systems. It is brain-numbingly stupid to network the monitoring systems because you really can't afford for them to be down... but they aren't able to cause a melt-down by being infected.
And NONE of that has to do with LINUX! It is flotsam... trash... rubbish... an attempt to distract from your inability to answer the points you made in 3a.
LOL, are you kidding? Or do you seriously not know about the level of attempts on Linux machines?
They are difficult targets but are hotly desired. I get hit about 50 times a day on my firewall (none of which get anywhere but they try). When someone gets their claws in a Linux machine it is very hard to get them out if they know what they are doing.
You really need to look up some information on rootkits. The odds of someone getting in are low but this does not mean they enjoy some "respected" status with crackers. Crackers will take whatever they can get and they love a Linux box... it is a prized gem.
It is a testament to the durability of Linux that it is not more common than it is for the breakins to happen. This is because most things are secure by default.
Edit: Actually, you need to go read up some dissection of compromised machines. Not only will it show you a lot about the security of Linux (and some of its problems) but it also will blow your points in 3a right out of the water. Well over 90% of all the dissections I have ever read have logs which show the cracker clearly was NOT Linux proficient. Often they try DOS commands, constantly need to read man pages for simple options which any normal Linux user would know off-hand, and clearly show no indication of how to clean up their tracks (often their commands are in .bash_history which is a clear indication they don't use Linux or they would know to remove that).
So, that goes right against your point of Linux crackers being the main ones out there. The vast majority of crackers show a surprising lack of knowledge about Linux. It is rare to see the work of a master... and usually they are caught by honey-pots as the system they hit would be cleaner than they found it and have no record of their visit.
>> "those of us who pay any attention at all to security have already read the article."
How many Linux home users is that? 90%...20%...1%?
>> "Many systems are not affected by this (mine for example.)" How the hell is that helping?
>> "that comes down to sysadmin sloth (laziness)" Do home users have to be System Admins now?
>> "Choosing an outdated distribution (e.g., Debian), or a poorly-managed distro..."
Honestly! Would anyone knowingly install an outdated or poorly managed distro?
I'm a newbie: You expect ME to tell YOU which distros/kernels suck?
If you are the experts, shouldn't you be telling me that?
This is is just the kind of rich white kid university grad drivel I've come to expect from America's arrogant middle class twits. Makes you want to purchase a couple of crate-loads of handguns,
and hand them out to black kids under twenty-five with a Hollywood 'star-map'.
If you buy an old Chrysler from the '70s, don't expect airbags.
If you buy any car prior to 1986, don't expect a third brake light.
If you do not know what was available with each, be prepared to do some research and RTFM.
LIkewise, when picking a *nix variant/distribution, you should expect to do some research - and RTFM. Not doing your own footwork - even as a newbie, a consumer - is your own fault. No one forces you to choose a distribution that hasn't been updated in years. It's akin to choosing Windows 95 over Windows XP and then wonder why you get hit by every DOS, Win3x, and Win9x virus known to man.
You are posting that in a security forum on a linux board. Thus my response, those of us who pay attention to security (aka those who would be reading and responding to your thread here) have already read the paper. It is also likely that others have read it as well (it hit slashdot and osnews recently). That has nothing to do with smugness. It has to do with knowing your audience. You aren't talking to my step-mother (who happens to run *nix but wouldn't be in the group to pay attention to such thing).
I also pointed out that this was not a problem affecting ALL systems. My system was fine right out of the box. I didn't have to change my ulimits. Debian (oddly enough considering someone else's response) was also one of the systems unaffected. The BSDs were not affected. Many systems were not. It was not a universal problem.
You posted something and people responded to it. Are we supposed to just smile and nod? Is that how you want us to act... are we supposed to support your maniacal ravings and say, "Hmm, he does have a point about that BIOS thing..." even when we know it isn't valid? No one here is fooling around with you or trying to say stuff just to make their own head feel bigger. You posted concerns and we tried to address them... then you continued to bounce around our replies and ignore the points.
What's up with the racial crap at the end. That's not cool. Drop that stuff now. This is not a black and white issue... skin color has nothing to do with it. And, for your information, I'm not exactly the person who would have a problem walking down the middle of the street in a ghetto at 2am in the morning. So shove it!
Which questions have we not sufficiently answered?
How about a good answer to your statements made in 3a? Remember... we like the facts not opinions and assumptions. You have not backed any of your statements -- the best you have done was posting that security report, which could have led to an interesting discussion if it was on topic. I even addressed that report and pointed out which area I thought represented the greatest risk (considering our discussion of locally executing code as a user).
No one is asking you to apologize for anything. We are asking that you drop the crap (like anecdotes which don't apply and racial comments) and support your ideas with some basis of knowledge.
If you said, for example, "What type of protection does Linux have against local root exploits and what happens when it is broken?" Then you would have a point... and we could talk. We might like to see a link to whatever caused you to think of that question so we know what exactly you want addressed.
But you have been talking about conspiracies of Linux crackers trying to kill Windows, hardware exploits which are from the 80s, and other assorted things which have no bearing on this conversation.
Stop playing the victim... because no one is buying.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.