Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Remote Code Execution Hole Found In Snort

kdawson posted more than 7 years ago | from the upgrade-right-now dept.

Security 95

Palljon1123 writes "A stack-based buffer overflow in the Snort intrusion detection system could leave government and enterprise installations vulnerable to remote unauthenticated code execution attacks. The flaw, found by researchers at IBM's ISS X-Force, affects the Snort DCE/RPC preprocessor and could be used to execute code with the same privileges (usually root or SYSTEM) as the Snort binary. No user action is required." Sourcefire has an update to fix the vulnerability in versions 2.6.1, 2.6.1.1, and 2.6.1.2; Heise Security spells out the workaround for the 2.7.0 beta version.

Sorry! There are no comments related to the filter you selected.

Year of the .. (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18091766)

Pig!

Re:Year of the .. (5, Funny)

gbobeck (926553) | more than 7 years ago | (#18091848)

Year of the ... Pig!

Boaring!

Re:Year of the .. (1, Funny)

Anonymous Coward | more than 7 years ago | (#18093658)

Quit hogging the first post

SANS (4, Informative)

azakem (924479) | more than 7 years ago | (#18091860)

Also covering this one: SANS ICS [sans.org]

The very definition of irony (3, Insightful)

Anonymous Coward | more than 7 years ago | (#18091876)

Something designed to make your network secure turning out to be a security risk...

Re:The very definition of irony (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18091936)

followed by a detection being created in the product the exploit targets....

Re:The very definition of irony (0)

Anonymous Coward | more than 7 years ago | (#18092004)

Something designed to make your network secure turning out to be a security risk...

Ironic? Surely you mean alanic? [urbandictionary.com]

Re:The very definition of irony (1)

dotgain (630123) | more than 7 years ago | (#18092056)

No, it's 'Alanic' when someone on slashdot uses the word 'Irony' properly, as the GP did.

Re:The very definition of irony (0)

Anonymous Coward | more than 7 years ago | (#18092996)

Whoosh?

Re:The very definition of irony (1)

pilkul (667659) | more than 7 years ago | (#18092098)

Ack! Thanks to that annoying song, not only do people frequently misuse the word "irony", any genuinely correct use (such as the GP's) is immediately attacked by idiots who claim it's incorrect. Curse you, Alanis! Curse you!

Re:The very definition of irony (1)

skymt (968075) | more than 7 years ago | (#18100696)

Grif: So now we're forced to work together. How ironic.
Simmons: No, that's not ironic. Ironic would be if we had to work together to hurt each other.
Donut: No. Ironic would be instead of that guy kidnapping Lopez, Lopez kidnapped him.
Sarge: I think it would be ironic if our guns didn't shoot bullets, but instead squirted a healing salve that cured all wounds.
Caboose: I think it would be ironic if everything was made of iron.

TWO HOURS LATER

Church: Okay. [slowly] We're all agreed that while the current situation is not totally ironic, the fact that we have to work together is odd in an unexpected way that defies our normal circumstances. Is everybody happy with that?

Re:The very definition of irony (1)

Checkmait (1062974) | more than 7 years ago | (#18092294)

Well, "the most secure Windows ever" comes close.

But what gets to me is the fact that people are attacking security applications.... successfully.

Re:The very definition of irony (1)

JensenDied (1009293) | more than 7 years ago | (#18092348)

surely you are not trying to imply that my av software is the target of a virus.

Re:The very definition of irony (3, Informative)

whoever57 (658626) | more than 7 years ago | (#18092312)

Something designed to make your network secure turning out to be a security risk...
Unfortunately, Snort seems to a history of such vulnerabilities. [google.com]

Ironic? Hardly. (1)

Dolda2000 (759023) | more than 7 years ago | (#18092372)

Irony? I would tend to disagree -- rather, I think it is to be expected. Snort is a perfect example of the kind of "solution" that, instead of fixing the real problems, just adds another layer on top of everything to cover them, increasing the overall complexity of the system, and the more complex a system gets, the more likely it is to show unexpected behavior. That kind of reasoning also perfectly well explains why Windows will never be as secure as any Unix flavor.

Re:The very definition of irony (1)

Jessta (666101) | more than 7 years ago | (#18092984)

Good security is assuming that all you software is a security risk and acting accordingly.

Remote, what about stealth installations (4, Insightful)

Gothmolly (148874) | more than 7 years ago | (#18091972)

Its a remote overflow, does it work if the sensor doesn't have an IP address? If it merely sees the right pattern of 1s and 0s on the wire, it roots itself? Article sadly lacking detail.

Re:Remote, what about stealth installations (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18092276)

If it is actually able to execute code, then part of that code could be to establish an IP address, open up a port, send out a beacon, whomp the box, etc...
Shellcode for a backdoor is the classic example but any small amount of bootstrap code could execute.

On an unrelated note: This exploit shows a weakness in the default Linux/UNIX security model: SNORT basically has to run as root in order to listen to raw traffic (and that is probably a good thing too). However when it does so, the rest of the program also runs with root privileges, including complex and bug-prone things like protocol analyzers (like the RPC analyzer).
There are some solutions for this, snort could be re-coded using privilege separation similar to openSSH, but that would probably be too slow for a program like snort (the speed is not much of an issue for SSH).
Alternatively, something like SELinux could contain the snort process to put it into a restricted domain where even having root privileges would not allow snort to execute other programs, open non-typed files (like shadow) or to make syscalls for opening sockets/getting IP addresses. Main problem with SELinux: Not always easy to use. The good news: Usually people running snort for real should know it. Issue: How many Linux based installs of snort are actually protected in any real way????

Re:Remote, what about stealth installations (3, Insightful)

Anonymous Coward | more than 7 years ago | (#18092342)

To reply to myself:
    From snort 2.6:

-g Run Snort as group ID after initialization.
                        This switch allows Snort to drop root privileges after
                        it's initialization phase has completed as a security
                        measure.

That could be very helpful if the group is nobody or another group not allowed to mess with the rest of the system. Once again, it has to be used properly though.

Re:Remote, what about stealth installations (2, Insightful)

JensenDied (1009293) | more than 7 years ago | (#18092396)

Isn't this why we use chroot for things like this?

Re:Remote, what about stealth installations (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18092522)

Isn't this why we use chroot for things like this?


A chroot jail is good, but unless I'm mistaken it only cuts off access to the global file namespace. The rooted process can still make system and network calls that could do quite a bit for an attacker, although taking over the whole machine would still require the ability to effectively escape from the chroot jail.

Re:Remote, what about stealth installations (1)

TheSkyIsPurple (901118) | more than 7 years ago | (#18092734)

Just getting root even without the FS is bad enough though... gets you by lots of firewally fun, and alot of folks thinkg a firewall is good enough security. You also have access to the memory space and processes and such, so you can really direct probes and such.

Oh such fun to be had =-)

Re:Remote, what about stealth installations (1)

Raenex (947668) | more than 7 years ago | (#18111928)

I take it you really like the word "such"?

Re:Remote, what about stealth installations (1)

Plutonite (999141) | more than 7 years ago | (#18099680)

If you have root priviliges, chroot is pointless. You can easily break out. [bpfh.net]

Re:Remote, what about stealth installations (3, Insightful)

Anonymous Coward | more than 7 years ago | (#18092858)

Good point. This is also another reason to implement a passive only tap [snort.org] for your snort box. In that situation the worse case scenario is your sensor sniffs some traffic that causes it to get compromised and it stops working or at least not correctly. Even if somehow a worm gets injected into the system from this passive sniffing it can't go anywhere. Unless your dumb enough to have your IDS machines hooked up to your internal network via another NIC. Keep your IDS sensors passive and isolated!!!

Re:Remote, what about stealth installations (3, Informative)

gbobeck (926553) | more than 7 years ago | (#18093862)

I did a network security project [luc.edu] for a class at Loyola University Chicago not too long ago. As part of that project, I built a passive ethernet tap [luc.edu] .

There are a few problems with passive taps...

1. They *don't* work with gigabit ethernet. If I remember the spec for gigabit ethernet correctly, this has something to do with the fact all of the wire pairs are used for XMIT and RECV.

2. The passive tap in the link you provided isn't exactly good for your network. This tap will still draw current as well as introduce some interference. In the worst case, you can blow a NIC with one of these. Of course, the easiest way around these problems is to use a hub (do not use a network switch as that won't work... you need a HUB).

3. You will need to run 2 NICs (1 for XMIT, 1 for RECV) in order to examine full duplex traffic. This may be an issue if you are trying to run snort on an embedded device.

If I had the option, I would rather run a spare computer as a Linux (or BSD based for that matter) firewall box and use port mirroring to mirror ethernet traffic over IEEE1394 (firewire) to another box running snort. The only downside is that ethernet over firewire is at best a 400 megabit connection.

Re:Remote, what about stealth installations (1, Informative)

Anonymous Coward | more than 7 years ago | (#18094870)

1. Umm, yes they do. Or at least ones other than snort do.

2. WTF? A switch will work just fine unless it's a POS.

3. Still don't know what you're talking about. Is this just a snort thing? Why would you need to transmit from a passive sniffer? It's freakin' passive.

Re:Remote, what about stealth installations (1)

TheNinjaroach (878876) | more than 7 years ago | (#18095930)

2. WTF? A switch will work just fine unless it's a POS.
I think he's referring to the fact that once you plug it into the switch, traffic that isn't destined for the tap simply won't be "switched" to its port. On the other hand, hubs pass all traffic to all ports. Our Network Admin here can enable a "Span" port on a switch though that will send all traffic, no matter the destination, down that port for inspection.

Re:Remote, what about stealth installations (0)

Anonymous Coward | more than 7 years ago | (#18096210)

Right. I was assuming the GP knew about span ports, but maybe he didn't.

Re:Remote, what about stealth installations (1)

gbobeck (926553) | more than 7 years ago | (#18097978)

I know about span ports, but I totally forgot to include them in my post.

Re:Remote, what about stealth installations (0)

Anonymous Coward | more than 7 years ago | (#18099876)

Hey, since you're back, let me ask you to expand on why gigabit ethernet won't work. I'm confused about that since there shouldn't be any problem linked up as and reading packets at 1 Gb/sec in my experience.

Re:Remote, what about stealth installations (1)

gbobeck (926553) | more than 7 years ago | (#18102120)

Hey, since you're back, let me ask you to expand on why gigabit ethernet won't work. I'm confused about that since there shouldn't be any problem linked up as and reading packets at 1 Gb/sec in my experience.


The best explination I can give comes from the Wikipedia entry for gigabit ethernet [wikipedia.org] . I have put in bold the exact technical reason why a passive ethernet tap cannot work with gigabit ethernet.

1000BASE-T (also known as IEEE 802.3ab) is a standard for gigabit Ethernet over copper wiring. It requires, at a minimum, Category 5 cable (the same as 100BASE-TX), but Category 5e ("Category 5 enhanced") and Category 6 cable may also be used and are often recommended. 1000BASE-T requires all four pairs to be present and is far less tolerant of poorly installed wiring than 100BASE-TX.

Each network segment can have a maximum distance of 100 meters, although several chip manufacturers claim 150 meters. Autonegotiation is a requirement for using 1000BASE-T according to the standard. Several device drivers will allow you to force 1000 Mbps full duplex to eliminate autonegotiation issues.


You may also want to check out http://www.hardwaresecrets.com/article/231 [hardwaresecrets.com] .

Now, before anyone chimes in "...but 1000BASE-TX only uses 2 pairs...". Yes, this is true, but the Wikipedia article linked above states:

However, the two-pair solution required Category 6 cable and has been a commercial failure, likely due to the rapidly falling cost of 1000BASE-T products combined with the Category 6 cable requirement. Many 1000BASE-T products are advertised as 1000BASE-TX due to lack of knowledge that 1000BASE-TX is actually a different standard.


Hope that helps.

Re:Remote, what about stealth installations (1)

TCM (130219) | more than 7 years ago | (#18095788)

Have you looked at any professional switch at all?

My cheap "web-managed" switch allows me to specify a monitor port where all traffic from (an)other port(s) gets duplicated to. This port is not a member of any VLAN and has non-tagged ingress traffic blocked. So effectively it's a send-only tap from the switch's POV.

Any halfway decent switch can do that.

Re:Remote, what about stealth installations (1)

hawg2k (628081) | more than 7 years ago | (#18096774)

Re #2 above, yes. Cat [56] has a 100 meter limitation. Depending on the type of TAP, you need to factor the length of wire on both sides of the TAP, plus ~ 10 feet for the TAP itelf. So the length of wire from the switch/router/server to side A of the TAP + the length of wire from the switch/router/server on side B of the TAP + ~ 10 feet must be = 100 meeters.

Been bitten by this one a few times. It's a real b!tch to troubleshoot, depending on how close to 100 meters you are. It works - doesn't work - works - doesn't work - ...

Re:Remote, what about stealth installations (1)

accessdeniednsp (536678) | more than 7 years ago | (#18096492)

I agree. In all of my IDS deployments, Snort is started with snort -u snort -g snort so I don't understand how/why people are using root, and why a default install would be setup that way. Haven't we learned anything from the last 30 years of Unix?

Somehow, this must be... (3, Funny)

Anonymous Coward | more than 7 years ago | (#18091994)

...Microsoft's fault.

Re:Somehow, this must be... (0)

Anonymous Coward | more than 7 years ago | (#18092406)

Yeah, someone must have been snorting something.

Re:Somehow, this must be... (0, Flamebait)

BSDetector (1056962) | more than 7 years ago | (#18092570)

Well, of course! Isn't everything? Slashdotters are idiots!

Silly Hackers (5, Funny)

tyrax (907001) | more than 7 years ago | (#18092096)

People who run linux don't have any money to steal.

Re:Silly Hackers (4, Insightful)

Lord Ender (156273) | more than 7 years ago | (#18092854)

People who run linux don't have any money to steal.

Every company large enough to need a Security team (you know, the companies with the most money) is going to be running Linux. Nearly all the best infosec tools are Linux apps. I know you are likely going for Colbert-esque humor here, but the fact is that companies that run Snort on Linux probably have much MORE money to steal, on average, than companies that do not.

Re:Silly Hackers (1)

Bacon Bits (926911) | more than 7 years ago | (#18095030)

Colbert-esque humor
The word is "satire".

Re:Silly Hackers (1)

Lord Ender (156273) | more than 7 years ago | (#18096302)

I am aware of that. But "Colbert-esque" just rolls off the tongue better, don't you think?

Re:Silly Hackers (3, Funny)

tsalaroth (798327) | more than 7 years ago | (#18097350)

Not to mention it increases the truthiness of your statement.

Re:Silly Hackers (0)

Anonymous Coward | more than 7 years ago | (#18096400)

I know you are likely going for Colbert-esque humor here, but the fact is that companies that run Snort on Linux probably have much MORE money to steal, on average, than companies that do not.
So, you know he was joking, but you couldn't resist acting like a pompous ass and stating the obvious as if it's insightful in any way. Got it. You must be a treat at work.

Re:Silly Hackers (1)

Lord Ender (156273) | more than 7 years ago | (#18098436)

There are big companies which run all Windows servers. A lot of people at places may not even be aware of the fact that their security systems run on Linux. They may think "we're a Windows shop, so this doesn't apply." That is why this was important to point this out.

My intended audience was not the poster specifically, but the slashdot audience as a whole.

Based on the fact that you missed the point entirely, and your post consisted of nothing but angry insults, I'm going to guess that you bring amiable personality to a whole new level.

Why this vulnerability? (4, Insightful)

madsheep (984404) | more than 7 years ago | (#18092226)

It is interesting this vulnerability makes it into Slashdot where other [past Snort/Sourcefire] vulnerabilities of the same magnitude have not. It would definitely be time to upgrade but the number of people running 2.6.1, 2.6.1.1, 2.6.1.2 and 2.7.0 beta 1 are probably not as wide spread as 2.4.x, 2.6.0, and probably earlier versions. Luckily this vulnerability has been identified by a bunch of good researchers and the potential exploit probably hasn't been developed by anyone malicious. The real fear here of course is not just that *a box* might get rooted.. it's that a box running Snort/Sourcefire might get rooted. Generally this box will of course sit inline on the network or have sort of span/mirror port running to it. Whenever an IDS, switch, or router compromise is possible it can truly spell bad news. However, I'd say in this case it's not likely that a whole lot would happen even if an exploit should be developed.

Re:Why this vulnerability? (2, Insightful)

tiny69 (34486) | more than 7 years ago | (#18092588)

Previous story submitters didn't allude to a conspiracy that the government is getting 0wn3d.

So (3, Funny)

OverlordQ (264228) | more than 7 years ago | (#18092340)

What's the Snort signature for this?

Would be somewhat helpful saying "Hey look somebody is rooting me!"

Re:So (0)

Zaknafein500 (303608) | more than 7 years ago | (#18092448)

You do have to appreciate the irony...

Re:So (0)

Anonymous Coward | more than 7 years ago | (#18092894)

Would be somewhat helpful saying "Hey look somebody is rooting me!"

Mom?

What I'd like to know is... (1)

kernel_panic (98119) | more than 7 years ago | (#18092350)

when will the signatures to detect this attack become available?

Re:What I'd like to know is... (0)

Anonymous Coward | more than 7 years ago | (#18092648)

They are out now.

(plus o!ne Informative) (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18092432)

Jesus Up the Smith 0nly serve

Disable the dce/rpc preprocessor (3, Informative)

caller9 (764851) | more than 7 years ago | (#18092712)

You shouldn't have the DCE/RPC preprocessor running, you shouldn't be exposing RPC to the internet anyway. FC6 default install of 2.1.1.2 has it disabled in snort.conf.

There are some instances where this should be running such as internal traffic monitoring, but I don't see how this can hit people from the internet with fragmented RPC traffic unless they're allowing it at the firewall.

Also, don't run any network service as root. FC6 install of snort does run as root by default, kinda lame.

-u username -g groupname arguments in the init script when starting the daemon will make it run as username:groupname credentials. nobody:nogroup maybe. Consider also chroot jail.

Old tips http://isc.sans.org/diary.html?date=2005-10-18 [sans.org]

Darn... (1)

flyingfsck (986395) | more than 7 years ago | (#18092732)

this made me snort my Coke and now I need a new keyboard, cause the keys are stuck...

Re:Darn... (1)

iamacat (583406) | more than 7 years ago | (#18093688)

Your noose bled that much? You should really cut down.

frist sto4? (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#18092930)

Don't be a Sling the most. LLok at lubrication. You

Shouldn't be running as "root". (1)

Animats (122034) | more than 7 years ago | (#18093262)

If an intrusion detection system has to run as root, it's part of the problem, not the solution.

Biggest single security problem with UNIX and Linux is that way too much stuff runs as "root". Too much trusted code.

Not that Windows is much better, although, in Vista, they're finally trying.

Re:Shouldn't be running as "root". (0)

Anonymous Coward | more than 7 years ago | (#18093920)

Biggest single security problem with UNIX and Linux is that way too much stuff runs as "root"

i think the largest issue here is having network applications running as root
and i do tend to believe this is because *Nix in general has chosen to make ports: 0-1023 priviledged ports bindeable by root only. This has led us to complicated and/or half-assed solutions like chroot, using iptables to forward low ports to high ports, ...
 
can anyone shed light on why we have wanted this in the first place
and yes i tried finding the appropriate source code but grepping the kernel source for the right instance of 1024,1023 is a very daunting task and i'm not sure in general if it's a good idea

Re:Shouldn't be running as "root". (1)

Animats (122034) | more than 7 years ago | (#18098418)

can anyone shed light on why we have wanted this in the first place

It was a Bill Joy thing in 4.2BSD. The idea was that UNIX systems could trust each other, but not their users. The old "rcp" protocol reflected this approach. The Berkeley guys were thinking of big multi-user time-sharing systems under central administration, not single user systems.

Early BSD team thinking was that it was good enough if BSD could talk to BSD. Interoperability with other TCP/IP systems had to be pounded into that crowd. BSD's TCP/IP networking didn't really interoperate properly until well into the 4.3BSD life cycle.

You're both wrong. (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18098606)

First, yes, there is way too much stuff running as root. Would you kindly point me to a system that doesn't have this problem?

But I would hardly call this the "biggest security problem", especially considering the vast majority of stuff does NOT run as root, and even daemons which must be started as root drop privileges later on.

It seems equally likely you'd find some bitwise monstrosity to an actual mention of 1024/1023, but in any case, there is a good reason for this. Think NFS, or basically any other service which doesn't have crypto layered on top of crypto -- even if I tunnel NFS through a VPN (which had its own problems, last I tried), that doesn't stop some local, non-root process of attempting to respond. In fact, suppose it's a fileserver that everyone boots from, and the NFS service has crashed. If we allow non-root to bind privileged ports, that also means non-root can then impersonate that NFS server and gain access to everything out there that relies on that NFS.

Now, NFS is arguably bad design here, but you get the idea. Connecting to a privileged port at least means you know what you are connecting to is owned by root, and thus sanctioned by the machine as a whole. If you're connecting to an unprivileged port, you really don't know if you're connecting to a service that the admin has actually set up, or something run by some user account.

I agree about iptables -- forwarding low ports to high ports is half-assed and stupid. Please at least try to understand the rationale behind a security measure before you willfully disable it.

Also, chroot can be complicated -- but it can also be very easy. However, it's not a replacement for the simplest rule here: Drop privileges. Once you bind to the port, you can drop root and become nobody, bound to that privileged port -- and the code that does that can be very simple. Simple enough that you can even throw it into a separate solution -- think inetd/xinetd, where the inetd itself must at least in part remain root, but your actual daemon (webserver or whatever) can be run as any user you like.

You may think this isn't always feasable, and to an extent, you're right. There may be parts to your program that must remain root. However, traditional *nix style would be breaking your program into small, cooperating programs and having only a few of those remain privileged. A good example here would be postfix -- it is split into five or ten processes, only one of which remains root, all others staying low-privileged and often chrooted. It may look strange and complicated at first glance, but it's actually a remarkably clean architecture.

Personally, I think Unix security is not really fine-grained enough. It provides the primitives that could be used to create a truly secure system, but at the moment, root is irrelevant on 99% of people's desktops. I have my su not even ask for a password if I'm in the "wheel" group, and I don't encrypt my SSH keys, because if someone 0wns my normal, everyday account, they've got me in every way that matters. What we want is a Postfix-like approach to per-user code. However, this is more on the desktop, "Let's get UAC right" side of things -- on the server side, it's actually pretty elegant as-is.

Re:You're both wrong. (1)

Raenex (947668) | more than 7 years ago | (#18112230)

Instead of only allowing root to bind to critical ports tt seems that the more flexible approach is to let the admin configure who can bind to those ports. And of course the default should be something secure so that not any random user can connect to the NFS port.

Those who don't understand Unix... (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18113578)

...are condemned to reinvent it, poorly.

Ok, let's assume your admin is root, or is able to run commands as root (through sudo). Let's also assume we have setuid bits, as I've never run into a Unix that doesn't.

Right now, we have the very inflexible approach, where the first 1024 ports are considered "privileged", and only root may bind to them. We also have a bunch of users with daemons designed to bind to some of those ports.

There are actually several really easy ways for root to handle this. The first, and most obvious, is to simply run xinetd, which is an internet superserver. It allows you to define services -- each service is a configuration of a port for xinetd to listen on and a program to execute when a connection is found. That program's standard input and output is connected to the connection.

So, only root can configure xinetd, but root can certainly configure it to run daemons as users -- supposing I wanted to be the one in charge of SMTP, I could simply ask root to forward port 25 connections to /home/sanity/bin/smtp, and run it as me.

Actually, I don't remember whether xinetd allows you to change the user under which a command is run, but that doesn't matter. The admin could easily customize that command to point to my user -- just put "su sanity -c /home/sanity/bin/smtp" as the command to run.

This may not provide as much control as you want, of course -- users can't control whether a port is open or closed. It's certainly less efficient; a new process must be spawned for every connection -- although that is more efficient if you have a lot of services that are connected to almost never, so you won't actually need any daemons running most of the time except xinetd.

But if you wanted to make it better, it seems like it would be much easier to write something like xinetd, or even just a small program runnable under sudo. It is possible (though tricky) to pass open sockets through to exec()'d programs, and even if it weren't, one could always write a server which bound to a socket, dropped privileges, and then called a user-defined library.

The downside to this is, of course, you have to write daemons to expect one of the above approaches. If you want to work with existing programs -- for instance, if you want to be able to start Apache unprivileged -- that is when you would start to implement something more complex. At this point, SELinux probably provides what you want, but it also requires kernel patches and introduces a LOT more complexity for the admin to manage than simple xinetd rules. However, properly configured, SELinux should allow you to run most existing stuff unmodified -- if I understand it right, you could probably configure apache to be allowed to open port 80 (even when not run as root), or even configure it to run as root, but not be allowed to do anything other than open a port and drop privileges.

I still like the root-only approach, though, as it's very simple and very clean, especially in terms of kernel code. The kernel only has to check whether it's a privileged port, and whether the user is root -- all the complexity is pushed out to userspace.

Re:Those who don't understand Unix... (1)

Raenex (947668) | more than 6 years ago | (#18116034)

Those who don't understand Unix are condemned to reinvent it, poorly.

I don't understand your argument. You admit that "root only" ports are inflexible. You admit stuff like xinetd are sub-optimal workarounds. You then propose that if xientd doesn't work for you to do our own ad hoc stuff that you say is tricky and doesn't work with existing programs. And if that doesn't work, you propose SELinux but say it "introduces a LOT more complexity".

How is my proposal reinventing Unix poorly? I'm saying the ports should be treated like any other device/file in Unix, by allowing the administrator to assign group/user privileges. Doesn't this fit in with the Unix model, instead of some arbitrary and unflexible rule that "the first 1,024 ports are root only", or some ad hoc, suboptimal, or complex workaround?

Re:Those who don't understand Unix... (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18122864)

doesn't work with existing programs.

Yours could, but it's tricky -- and I think mine could, also. Network devices used to be implemented as files, and now they're not. I suppose there could be a compatibility layer, it just strikes me as somewhat fragile.

But go ahead and prove me wrong. Implement this in a nice, clean way.

Most programs already do this for me, anyway -- like I said about Postfix. Most daemons do have good reason to be started as root, also -- it lets them drop privileges. For instance, OpenVPN needs its key files in order to establish a connection, but once the connection is open, it can be dropped to nobody.

I'm saying the ports should be treated like any other device/file in Unix, by allowing the administrator to assign group/user privileges.

That would be nice -- but that requires a large chunk of kernel code -- and, like I said, this has apparently been discarded before.

Doesn't this fit in with the Unix model, instead of some arbitrary and unflexible rule that "the first 1,024 ports are root only"

No, now you're installing arbitrary policy into the kernel.

or some ad hoc, suboptimal, or complex workaround?

Ah. See, my first solution, I thought was actually somewhat elegant. That's the thing about sudo and setuid, they can be used to implement almost anything, which means the kernel doesn't have to know anything beyond "only root can access these".

The Unix model is more about creating a simple set of primitives from which you can build anything you need. So, setuid fits more into that model -- just as, with sudo, the only thing the kernel has to know is setuid, and then sudo can implement its own policy about what commands the user is actually allowed to run.

But you may be right, it may be time to replace parts of the current model. But if it is, I'm not sure you've got the right idea here. I do have an elaborate plan to replace Unix, but before I do, I'm trying to understand it as thoroughly as I can.

Re:Those who don't understand Unix... (1)

Raenex (947668) | more than 7 years ago | (#18125404)

I do have an elaborate plan to replace Unix

Good luck with that :)

Horrible code (0)

Anonymous Coward | more than 7 years ago | (#18093426)

I looked once on their code. it's a horrible mass of undocumented, non-modular, un-resuable code.
In the end I decalred their code unusable, and the developement took other direction.

You FAI:L it (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18093448)

Re:You FAI:L it (goatse) (1)

clawoo (945374) | more than 7 years ago | (#18093472)

We're talking pigs here, not goats. Dumbass.

snort shouldn't be running as root (1)

TheLink (130905) | more than 7 years ago | (#18093660)

Or at least it should be splitting itself up so that the module that grabs all traffic is separate from the module that does significant processing of the traffic (which hopefully then gets locked down),

Snort has had a pretty poor track record for this (for that matter tcpdump has also had similar problems).

Completely unnecessary (4, Informative)

Vintermann (400722) | more than 7 years ago | (#18093716)

Why oh why are we in 2007 seeing code like this in security apps? input verification in the classical C way with pointer arithmetic on strings.
(and no, the error isn't there, it's just the first thing I came across in the snort source)
Why are they even using C? Suprise, they make exploitable buffer overflow attacks! And they still have one verified, non-fixed issue detected by coverity, plus 33 "uninspected and pending" according to coverity's scan [coverity.com] .


int CheckRule(char *str)
{
        int len;
        int got_paren = 0;
        int got_semi = 0;
        char *index;

        len = strlen(str);

        index = str + len - 1; /* go to the end of the string */

        while((isspace((int)*index)))
        {
                if(index > str)
                        index--;
                else
                        return 0;
        } /* the last non-whitspace character should be a ')' */
        if(*index == ')')
        {
                got_paren = 1;
                index--;
        }

        while((isspace((int)*index)))
        {
                if(index > str)
                        index--;
                else
                        return 0;
        } /* the next to last char should be a semicolon */
        if(*index == ';') ...

Re:Completely unnecessary (0)

Anonymous Coward | more than 7 years ago | (#18094206)

At least if you could point out the actual
overflow you could mabey make your point.

But doing a coverty lookup and pasting a
bit of code used for rule parsing not exposed
remotely dosent make the point.

Somtimes it is possible that some bugs slip out of the hands
of the programmer, but it dosent have to be blamed on the
man behind the code or the language.

If you feel unsafe writing C use python or your favorite
"language".

And even if you would erradicate Buffer Overflow you are still
exposed to logical bugs, execution path subvertion, trust
bypass and many other security nasties.

-someone to lazy to register

Re:Completely unnecessary (1)

Vintermann (400722) | more than 7 years ago | (#18094410)

To lazy to have proper spelling, too. Certainly too lazy to write software I will use to protect my computers.

To this:

And even if you would erradicate Buffer Overflow you are still
exposed to logical bugs, execution path subvertion, trust
bypass and many other security nasties.
I quote Babbage:

If you speak to him of a machine for peeling a potato, he will pronounce it impossible: if you peel a potato with it before his eyes, he will declare it useless, because it will not slice a pineapple.

Re:Completely unnecessary (1)

raddan (519638) | more than 7 years ago | (#18097898)

To lazy, or not too lazy: that is the question.

Re:Completely unnecessary (1)

Raenex (947668) | more than 7 years ago | (#18112464)

Nice quote. I haven't seen that before. I agree with you -- it's truly sad that in 2007 people writing security software are doing it in C with pointer arithmetic.

Re:Completely unnecessary (1)

eli pabst (948845) | more than 7 years ago | (#18100350)

OpenBSD is written in C. Maybe you can show us why OpenBSD is insecure.

The "pending and unverified" status is essential a useless metric because Coverity uses an automated scan which is inherently prone to false-positives. Even so, from their site it looks like it's results are comparable to Apache.

Re:Completely unnecessary (1)

Random Walk (252043) | more than 7 years ago | (#18101834)

C is the only really portable language with decent performance. Java et al. is fine on M$ and Linux, but what if your application should be able to run just as well on some dozen of other operating systems which may not even have an implementation of your favourite managed language (and if, one that is slightly incompatible with all other implementations of that language)? Things may be improving, but at the time the snort project was started, there certainly was no alternative with respect to portability and performance.

Now can we stop using C, please? (1)

master_p (608214) | more than 7 years ago | (#18094146)

Can we stop now using C, please? pretty please?

how many more buffer overflows do we need to get persuaded that C does not cut it any more? working at 95% of the cases is not good enough in this day and age.

How many times does it have to be said? [slashdot.org]

Re:Now can we stop using C, please? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18095908)

Nobody is stopping you from writing your own IDS in whichever language you choose. Quite whining and start coding.

C is enough, much as I hate it (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18098688)

Buffer overflows are the result of bad C programming, not of the C language in itself. You can, actually, do OO in C, and it's actually a nice lightweight language when compared to, say, C++ and Java.

Personally, I wish we saw more "scripting" languages around, but those don't cut it either as soon as you start to care about performance. Getting there, but nowhere close to C... yet.

Re:C is enough, much as I hate it (1)

DimGeo (694000) | more than 7 years ago | (#18103498)

Apart from C++ taking bloody ages to compile, you can actually end up with smaller code when writing in C++, but it's damn tough to do it - and so that's not a real argument for C++.

Anyway, even if C++ == bloat, you can still use stl's std::string, std::vector and std::map for most of the simple programming tasks. Sure, they're slow. They add like 1 meg of code bloat and stuff. But you don't get nasty errors from dealing with pointers and memory allocation stuff. And for a userland app that's perfectly reasonable performance-wise. And it's sure not as "bloated" as Java (hint: I like Java, but it's not for everything). If you know what you're doing and you don't mind pulling your hair a lot, stick with pure C, it's more portable, does only what you tell it to do, no hidden surprises, etc. But if you just need to get something done quickly, please, please, use STL You don't have to be using classes or templates and stuff in your own code, just stick with STL. It works on enough platforms already, and it automagically adds a HUGE layer of security.

Re:C is enough, much as I hate it (1)

master_p (608214) | more than 7 years ago | (#18106734)

You can do anything in assembly, but that is not an excuse for using assembly. That's why no one uses it anyway.

Re:C is enough, much as I hate it (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18112850)

Assembly is not portable. C is.

Most other languages have significant drawbacks in their respective implementations, or add too much bloat in implementation or understanding. It's hard to make a good case against C, though -- most things that are possible in other languages are possible in C, yet there are plenty of things that are possible in C which are not really possible in other languages. For example, I wouldn't consider writing a kernel in Java -- yet.

I don't use C, but I also don't think other projects are making some hugely horrific mistake in choosing it over another language. It's possible to write bad code in any language, so you should base your choice more on what you can do with it than how many ways you can screw up. This is also an argument for Perl, by the way -- just because it's possible to write Perl code that looks like line noise shouldn't stop you from using it. And just because Java is going to force you to write cleaner-looking, more verbose, documented (for your own sake) code doesn't mean you should automatically choose Java instead of Perl.

Personally, I prefer shell scripts when they make sense, and Perl when it's too much to sanely do in bash. But that's convenience.

Re:C is enough, much as I hate it (1)

master_p (608214) | more than 7 years ago | (#18120372)

Assembly is not portable.
It could have been through bytecode. But no one programs in bytecode.

C is.

It is not. C does not define binary layout, for example, and therefore data structures may be used differently in different architectures. There are lots of other things that make C non-portable.

Most other languages have significant drawbacks in their respective implementations, or add too much bloat in implementation or understanding.

There are other languages that offer very little on top of C, with much greater improvement in productivity, security, safety and decreased cost.

It's hard to make a good case against C, though

Actually, it is very easy: you can't do tail recursion optimization, you can't do continuations, you can't have decent garbage collection which exploits the type system for certain optimizations, you can't have non-nullable pointers, you can't have strong types, etc

-- most things that are possible in other languages are possible in C, yet there are plenty of things that are possible in C which are not really possible in other languages. For example, I wouldn't consider writing a kernel in Java -- yet.

There are other languages much better than C that offer the same or better control and much greater safety: ADA, Cyclone, Dylan, Erlang etc

I don't use C,

Really??? I couldn't tell...

but I also don't think other projects are making some hugely horrific mistake in choosing it over another language.

The question is, how can you say that since you do not use C.

It's possible to write bad code in any language,

What you do not understand, though, is that C does not scale up. Chances for critical errors rise exponentially to the size of a C project.

so you should base your choice more on what you can do with it than how many ways you can screw up.

It depends on what program you write. If you write a simple game or a program for your own use, go ahead and use anything. But if you are into a big project, an important one, please don't use C.

Re:C is enough, much as I hate it (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18123294)

C does not define binary layout, for example, and therefore data structures may be used differently in different architectures.

There are plenty of portability libraries. In C, as in Perl, most of the porting has already been done for you.

There are other languages much better than C that offer the same or better control and much greater safety: ADA, Cyclone, Dylan, Erlang etc

Of those, I've looked at Erlang, and as far as I can tell, it's too slow and inflexible. And yes, I know it's used in mobile phones, etc.

The question is, how can you say that since you do not use C.

I should've said, I don't use it for my own stuff. I do occasionally hack around in C, and I see people doing good stuff there.

What you do not understand, though, is that C does not scale up. Chances for critical errors rise exponentially to the size of a C project.

By this, do you mean, chances for any errors, or a number of them? I'd say, look at the Linux kernel lately.

But if you are into a big project, an important one, please don't use C.

I intend to stay as far away from C as I can, most of the time. I just don't think it's the only "right way".

Buffer overflow is the price to pay... (0)

Anonymous Coward | more than 7 years ago | (#18095134)

For programmers refusing to use newer technologies making buffer overflow a thing of the past. And please don't start talking about performances: it's really pathetic to see all those supposedly written in a fast language single-threaded apps running dog slow on all these newer multi-core CPUs.

I'm not necessarily talking about something like a Java VM, which hasn't had a single buffer overflow since it exists (except when linking to some Linux third-party C written libs). There are solutions for good ole' C programs too.

A buffer overflow, from people pretending to write application concerned with security. FFS!

Common, security conscious people, it's 2007, wake up... We want secure multi-threaded apps.

Re:Buffer overflow is the price to pay... (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18098788)

And please don't start talking about performances

Ok, I'll talk about performance. Performance in this context is never, ever plural, unless you were talking about, say, dance performances.

But seriously, look at your Java VM. Look for all the benchmarks and justifications you like, but the fact is, I still have to wait on my machine in order to try Hello.java. It feels slow, and I can actually go find some benchmarks to prove it is slow.

single-threaded apps running dog slow on all these newer multi-core CPUs.

Which becomes irrelevant when you run more than one of them.

Now, I actually agree with you -- in theory, a VM should be as fast or faster than C. In theory, multithreaded apps should be easy to write. And yes, in practice, there are ways to protect yourself from buffer overflows, although it won't save you from other stupid mistakes.

However, the first two have a theory which hasn't caught up with practice yet (I'm working on that), and in practice, buffer overflows are really secondary to sheer programmer stupidity -- see the Tetris/plane exploit? The buffer overflow was what brought the whole system down, but there is no language that automatically saves you from allowing a user to put the system into an invalid state. With a phone.

Re:Buffer overflow is the price to pay... (1)

LWATCDR (28044) | more than 7 years ago | (#18101612)

"But seriously, look at your Java VM. Look for all the benchmarks and justifications you like, but the fact is, I still have to wait on my machine in order to try Hello.java. It feels slow, and I can actually go find some benchmarks to prove it is slow."
You have to wait because you have to wait for the jvm to load.
Or the program was really poorly written.
Java isn't slow when the jvm is in memory. Imagine if you bench-marked helloworld.exe from the time windows started to boot until the program opened the window.

Re:Buffer overflow is the price to pay... (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18101950)

Or the program was really poorly written.

Hello, world? How, exactly, would I write that poorly?

At a second glance, however, you're right -- it's actually reasonably fast now. I distinctly remember having to wait quite awhile for just about any program -- and it was not disk thrashing, hard disk light was off.

Still, it will be awhile before you can convince me that Java is fast enough, and awhile more before you can convince me that the syntax is even tolerable. Yes, you can run other languages on the JVM, but it's not really designed for them.

Re:Buffer overflow is the price to pay... (1)

LWATCDR (28044) | more than 7 years ago | (#18108276)

It is hard to write a really bad hello world. However it is real easy to write very slow Swing code.
I like Java because it has a base object unlike c++ which is c with objects tacked on.
The support staff where I work calls back customers that request a support call so they don't have to wait on hold. I wrote the program that manages the support calls, RMAs, and issue tracking in Java using Postgresql as the back end. It has handled 300,000 support calls and I don't know how many RMAs over the years with no problems.

Re:Buffer overflow is the price to pay... (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18113658)

I like Java because it has a base object unlike c++ which is c with objects tacked on.

Great! Now explain to me why this is a good thing.

It has handled 300,000 support calls and I don't know how many RMAs over the years with no problems.

Alright, I'll give you this one.

I'm still looking for a language that is powerful, flexible, bytecode-portable, and at least close to as fast as C. Java may have the last two -- maybe -- but it's sadly lacking in the first two.

Re:Buffer overflow is the price to pay... (1)

LWATCDR (28044) | more than 7 years ago | (#18114848)

" I like Java because it has a base object unlike c++ which is c with objects tacked on.

Great! Now explain to me why this is a good thing."

Well I learned structured programing when I first started programing in the early 80s. I am a proud owner of Data Structures + Algorithms = Programs by Wirth. After banging my head on objects for a while I finally got it and found it to be a great way to program. It is extremely useful when dealing with threads. You may not like OOP but I find it very comfortable way to write stable multi-threaded code. BTW I am also writing multi-threaded code using c under Linux for an embedded project and yes it is stable but you really have to be extremely careful and debugging threads in c under Linux isn't a lot of fun.

Java's main limitations are ones that you will have with any bytecode environment. It isn't easy to access platform specific features but that is part of that price you pay for portable bytecode. Flexible, I have never found that Java gets into my way any more than c or c++ does. I will also admit that I really like Netbeans as an IDE but that is also a personal choice.
I still haven't found a prefect language but if you find one let me know. Of course I have heard a lot of great things about Smalltalk but I haven't learned it yet.

Re:Buffer overflow is the price to pay... (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18115732)

Erm... no, I know why OOP is a good thing. I don't know why Java OOP is any better than C++ "tacked on" OOP.

Explain to me why it is a good thing that the class "Object" exists? It seems to me that the only time you actually need to use it is when forceably typecasting stuff in a very un-OO-like manner.

Java's main limitations are ones that you will have with any bytecode environment. It isn't easy to access platform specific features

Except C# and .NET make this ridiculously easy, and are still somewhat cross-platform, thanks to Mono. What's Java's excuse?

There actually is someone I was talking to about a language he was creating, which sounds perfect. But therein lies the problem -- creating. Still nothing actually finished yet.

Privilege separation? (1)

Halo- (175936) | more than 7 years ago | (#18095270)

It's been a long time since I've used Snort, so maybe things have changed, but why the heck doesn't it use a privilege separation scheme to prevent things like this? It seems a lot of the packet decoders (Ethereal/Wireshark, Snort, etc) have a continuous trickle of buffer issues which lead to security exposures. Since we know that parsing is hard, why not do it across a well defined interface to a non-root process?

But wait! (1)

aybiss (876862) | more than 7 years ago | (#18105718)

I thought only evil M$ released code that has security problems. Didn't they patent it for Vista? :-p
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?