Slashdot Mirror

The use of the segmentation hardware is also what OpenBSD does for W^X (which means the system won't allow memory to be both writable and executable) on x86, but it's acknowledged to be a crappy hack far inferior to using the page-level execution bits on hardware that offers them (e.g. amd64, even in 32-bit mode).

So then you don't trust my agregation of facts because i got paid $75 for the article I wrote?

Spender didn't write PaX, he just built the code around it to add many additional useful protections to produce a complete security solution.

It's good to deploy stack smash protection as well. This protects stack based overflows in general, very high quality :)

I don't feel like going into details right now, as it's 2am.

Um. you don't need hardware. And java JIT does not need an executable heap, as I've shown. Realtime emulators like Qemu and VMWare need one. You need to add good, high-entropy ASLR to NX to seal it, otherwise it's evadable.

There are others too.

Here's a basic roundup of useful links:

• GRsecurity
• CIS Scan
• Openwall Project
• Bastille
• RSBAC
• SELinux

And why on earth would it be reasonable to take 90 days to produce what is usually something like an obvious 5-line kernel patch?

(1) the patch is probably more than "5 lines", because otherwise it would have been found earler.

Not true. To quote Linus, "In the case of "uselib()", it was literally four lines of obvious code - all the rest was just to make sure that there weren't any other cases like that lurking around." From other patches I've seen, this is typical. Often it's just a small oversight that needs fixing.

(2) security patches almost always IME have substantial side-effects and must be tested carefully

Again, look at the uselib patch: http://www.grsecurity.net/linux-2.6.10-secfix-2005 01071130.patch. It's pretty trivial--as far as I can tell, all it really does is take a certain kernel semaphore in a few places where it didn't before. Of course, nothing's certain--*any* modification could throw off the timing of some critical application just enough to trigger some race condition you hadn't seen before. But these things should be pretty safe.

(3) it takes longer than 5 days to QC, prepare, and release a patch for an enterprise-class system. I hope.

I understand that deploying patches faster than that is considered by many adminstrators of such systems to be a hard problem, but it's a problem that they will have no choice but to solve. People *are* going to figure out how to exploit vulnerabilities in under 5 days.

--Bruce Fields

The instruction and data sides have separate TLBs, so you can distinguish "readable" pages from "executable" pages by loading instruction and data TLBs separately. PaX does this.

Of course NX does not stop virusses and trojans. However, in itself it does only stop some memory corruption attacks, like simple stack overflows. But not many other types of memory corruption attacks.

NX is just one method to protect the integrity of the memory. What it basically does is that it allows an OS to implement separation between data and code in the memory of a running process. Many overflow and other attacks depend on writing data in the process memory and then executing it as if it was code. A virus or a trojan is usually a program. It depends on being run, not on memory corruption. Therefore protection against memory corruption brings you literally nothing.

NX in itself stops exploit writers for aproximately 15 minutes, which is the time it takes for them to adjust most of their overflows to make them work with NX. Only a hand full of attacks cannot be adjusted. So NX in itself doesn't bring you much, despite what the marketing departments of companies like AMD and Red Hat tell you.

The trick to provide good memory protection is not to only use NX, but to combine it with other protection methods. This is the approach taken by the PaX project http://pax.grsecurity.net/.

However, there are also some PaX imitations which, unfortunately, do not implement all of the PaX technology (even though some of them claim they do or claim to be even better). Examples are: MS-Windows SP2, Red-Hat's Exec-shield and OpenBSD's W^X.

Anyways, back from the technical intermezzo to AMD marketing. These guys have the same problem which people from the PaX project, exec-shield, OpenBSD and others who produce stuff like this have: Try to explain why this stuff is useful. If clever people like Linus don't get it, then how is one going to explain it to John Doe or the PHB's of this world? ``Memory corruption? Exploits? Buffer overflows?'' ``Woah! Brain overload!'' At least they have heard the word ``virus'' a few times and have learned that ``virus = bad''. So ``NX = good'', which cannot be explained to lusers, became ``NX = anti-virus = good''. Even if it is disabled by default, if you cannot motivate people to try to look for it, they never will.

Oh yes, these patches break things. Most programmers are spoiled. They think it is normal to mess around with memory in any way they like. Few of them understand that what is convenient for them, is also convenient for exploit writers. It's like MS-DOS programmers complaining about the file permissions on UNIX.

I hope AMD takes the challenge to produce better marketing, so more people start using this technology. Even though it is badly implemented in MS-Windows, it is a small step in the right direction.

Not only that, but Linux has had this for some time now, just not at the hardware level. OpenBSD (not sure about Net/FreeBSD) has this.

The PaX patch effectively implements this feature on older x86 processors that don't have hardware NX support. It takes advantage of the fact that data and code have separate page table caches.

It comes with a pretty high performance overhead, though. A page fault will occur for any miss of the TLB cache while normally they are just loaded from the page table in main memory.

My dear, go to the linked grsecurity homepage, jump over the "we're closing" message, take a look at the navigation menu and chose features.
Is your diaper wet again?!

As long as Linux is administrated well, you'll wind up with very little of anything really.

Occasionally, we find bugs in the kernel, like the mremap() bug and all. THESE are your major problems. They will get fixed quickly, though, and thus all distros will need to update their kernels to become protected against exploits of that persuasion.

Your next major problems are privilaged daemons. Simple stack smash protection takes care of most of the problems that let exploit writers get into these. PaX with its W^X philosophy for memory and its address space layout randomization also helps greatly; giving a process a 100% W^X address space will guarentee that no code injection can take place, and randomizing its address space will make it exceedingly difficult under most situations to do ret2libc attacks. There are cases where the address space can be mapped with %n format string bugs, thus defeating ASLR; but these are far and few, and you still should be relying on ProPolice or StackGuard to decrease the probability of these being exploitable by making the exploit condition a union between (RAM_is_mappable U ssp_is_evadable).

Once these two are in place, you have only a few, contained attack vectors to worry about: fork() bombs (there is fork() bomb protection somewhere that kills if you fork() too much too fast; plus kernel 2.6 just gets very laggy rather than locking out during a fork() bomb); and viruses/worms/trojans inside of users' accounts. But hey, even if user X gets bogged with spyware, you can in the worst case back up his documents (not his settings, they may contain spyware data) and flush his home directory; he's completely isolated from harming the system.

I'd still like a hierarchial namespace for shared memory and processes, so that i.e. chroot() jails could be further physically isolated. In Linux, every program gets its own virtual ram space (about 3GiB). Physical ram is mapped into that as needed, but every VM space is well isolated. IPC lets you pass shared memory segments back and forth and do shared mmap() data. There's also ptrace() to let processes interact. I'd love to see a way to create a "bubble" inside a "bubble" as (A(B)), so that tasks in A can send signals and access shm and ptrace processes in B, or push shm segments and mmap() shared ram into B for tasks in B to attatch to; but leave tasks in B otherwise unaware of tasks outside of B (i.e. in just A), so that they couldn't ptrace() out or get shm outside of their namespace. I can't think of any immediate uses for this right now, but it would give the potential to isolate untrusted programs pretty well; and eventually, the init scripts and some system policies could use it to isolate things automatically in a way that keeps processes that don't need to communicate away from eachother.

http://pax.grsecurity.net/
http://www.grsecurity.net/

"W^X" on Linux. (It even emulates it on i386)

So if you consider Linux to be a part of the "Linux community", then the answer is yes.

http://pax.grsecurity.net/
http://www.grsecurity.net/

"W^X" on Linux. (It even emulates it on i386)

So if you consider Linux to be a part of the "Linux community", then the answer is yes.

>> I use Linux on almost all my systems, but nothing can cut the security I get using OpenBSD on my firewalls and routers.

what about www.grsecurity.net? IMHO, I think grsecurity is much more a better solution especially if it were ever integrated into 2.6 kernels. Face it, what other patch/modification/os could potentially protect you from flaws in the kernel itself??

Here is a list of some things that I feel are worth considering:

1. Patch your system! As soon as a patch comes out, get it applied and reboot if you have to! Also, stay up to date on security issues by subscribing to mailing lists that are related to the software your using. One good general purpose site is cert.org. Keep in mind that while mailing lists are great ways of being notified, they arent fool proof. If your subscription expires and you dont know about it, you wont be exactly up to date in the community now will you?

2. Use grsecurity. This is a kernel patch that is briefly lagged behind official Linux kernel versions. It has many great features for protecting against stack attacks/buffer overflows. ie: Those latest greatest scripts your local script kiddie just downloaded wont likely do anything against you since special addresses are randomised. It can also hide files on your computer such as intergrity checkers so nobody except you know they exist. Plus it can stop insert code into a running kernel by making kernel memory readonly (which btw, would have prevented at least one of the attacks they mentioned).

3. Install a filesystem intergrity checker. Aide, integrit and tripwire all come to mind and essentially all do the same thing but with different config file syntax. Besides, how can you tell if a file is changed if you dont actually check? Also, dont forget to hide the existence of this program using something like grsec's gradm filesystem ACL util and be careful of automating checks in the crontab!

4. Read a good linux securing article. One such article I have read is called Securing & Optimizing Linux: The Ultimate Solution. It will teach you how to lock a system down a fair bit and how to remove unused/unneeded services from your computer.

5. Watch those logs! Log files provide a wealth of information, but administrators rarely check them (well, not all). If you dont know what a log entry means, research it, or else you may be looking at an attack and not even realise it. Now I know some of you are thinking I am nuts considering just how many logs even a small system generates, but there are tools to help you. One way is to use a program called swatch (a perl script). It can parse existing and old archived log files using a perl regex syntax and trigger actions based on found text. Start by configuring the system to ignore any log entries that are known to be friendly and show you everything. Then slowly eliminate each friendly entry one at a time. What will be left is a list of purely evil enteries :). Next configure swatch to alert you upon recieving such messages! Of course you can always use perl or even grep -v to parse logs, but for repeated use I think a specialised tool would save you some trouble in the long run.

Now I know I could go on forever with suggestions, but I think that these few things should give anyone a kick in the right direction. I hope this has been helpful.

As for the issue of the underlying OS providing security features, it's not entirely a moot point. Linux provides some stack/heap protection and other binary runtime security through the grsecurity patches; OpenBSD has W^X and other security features built into the kernel. Still, expecting the OS to protect binaries at runtime is a completely ass-backwards way of approaching security. Ultimately, application developers have to bear most of the burden for writing secure code.

x86 hardware has supported this kind of functionality for quite some time. Read the description of the grsecurity patches for linux that implement the functional equivalent on just about all platforms that linux runs on, including x86. The difference is that Microsoft didn't want to expend the resources to implement what a single individual has been able to implement on linux.

Further complicating the problem is that even if someone were to develop an environment that attempted to prevent all of the problems caused by programmer errors, it would be horrendously complex and would likely kill performance.

IMO, a big part of the solution is factoring out solutions for major known security problem areas into the environments, languages, and frameworks that developers use on a day-to-day basis. E.g. if you're using a language with robust automatic memory management, there's little reason to go looking for C-style buffer overflow exploits coded by your developers.

In today's environments (e.g. Windows and current *nix systems) with current popular languages (e.g. C, C++) we're at a big disadvantage. Much of the discussion in this thread presumes that coders can/should amass total knowledge of all levels of security exploits, from binary code injection to cross-site scripting (aka CSS), SQL injection, etc. It becomes overwhelming to a dev who really should be able to focus on the value-added problems at hand. I'm aware of only one cost efficient approach: choose environments, languages, and/or tools that mitigate known security risks.

Where applicable, this can be done by leveraging environments that can limit the scope of attacks. See SELinux and GR Security for ways to patch Linux to meet thess needs, or the EROS project for a fresh view of OS security and compartmentalization models. Environment choise is most relevant to folks providing networked services, where they can control the platform specifics.

The cause can also be aided by using languages/frameworks that encapsulate security knowledge. This can be as "simple" as using a language with automatic memory management(to factor out common buffer overflow problems), or along the lines of using scripting frameworks that standardize policies for correctly managing more complex security issues (e.g. cookie management, web input/output validation, CSS issues, etc).

I'd argue that it is possible to improve software security practices significantly simply by careful choices of tools and techniques available today. But it takes a saavy organization to really commit to providing secure software solutions, and to be able to do so in a cost effective manner. As always, the hard part of the equation is programming the wetware. 8-)

...with the kernel patches from http://www.grsecurity.net. Adds support for real acl's, chroot enforcement and lots more hardening of the kernel in general.

I've been using it in a shared hosting environment so that I can allow my users to have sftp only access whilst being jailed into their home dir.

With some documentation here: http://pax.grsecurity.net/.

BTW, reading on PaX you'll probably stumble on them badmouthing OpenBSD ("them" most likely being fanboys than developpers), this childish attitude from a certain base of users do them nothing but harm...

OpenBSD's W^X (magicpoint slides) and Linux grsecurity PaX both use that on x386 but it has its limitations, think for example that every shared library has its own code and data section (to oversimplify) and you have to do heavy manipulation to cram each part in the right segment... Having a per page protection is way better, more convenient and do not sacrifice usability for security (forget Java with PaX, OpenBSD gets by being slighly less secure, but at least not breaking well known Unix semantics like PaX...).

• UML
• ipsec
• ebtables & bridge-netfilter
• robert love's preemptable patch
• LSM-hooks (which make not everybody happy:grsecurity, RSBAC
• LS-module SE-linux
• filesystem-encryption
• apci 2.5 backports
• Kernel .config
• DVB-support

They must have beaten up Linus to get all those accepted ...

/graf0z.

grsecurity is a promising mechanism to un-root a linux kernel based system: ipaddr, user or group based roles open or deny access to privileged operations without ever having uid=0 to begin with. It's a bit complicated to use but the system can auto-learn and generate these policies. Also, the system includes PaX which does some neat things like scramble the stack to thwart buffer overflows, non executable pages, etc... I've played with both (well, Mandrake secure kernels have grsec compiled in, not shure about pax) and although I still can't figure out (read: "ready made & nicely packaged ;-)") all of it but it does give the warm & fuzzy feeling it makes a difference...

This exists!

Check out http://grsecurity.net, a great kernel patch that I personally thing should be merged into the default kernel.

Tim

Answer: My understanding is PaX would have preventented the integer overflow that comprimised kernel memory: the kernel would have paniced, never returning from the call. propolice prevents buffer overflows with stack guarding techniques introduced at compile time. Add grsecurity or selinux then you have a hardened system.

This may not catch 100% of the exploits but it's a solid start in the right direction.

There are various other methods currently being researched, typing speeds/patterns is the main one that could be used here but its not really reliable enough currently. For a major project like debian implementing some kind of smartcards wouldn't be beyond the realms of possibility (or budget anymore).

It is possible to limit break-ins like this using one of the various sets of ACL's around.

I'm not sure I agree with the point that "its not about the OS being secure".....well the OS has users, who tend to do things like write their passwords down, lose them or get themselves socially engineered. A truly secure OS should take this into account and have appropriate measures to limit the damage such a user could do.

when a M$ compromise comes to light

You mean, "when Microsoft have no choice but to annouce a break-in". With the loss of share price such announcements would cause don't you think they'd just keep them quiet? The problem is that Joe Public, and Joe Ceo both think this means that they are more secure because CNN doesn't carry stories about them being hacked. This is a problem with society, not open or closed source.

At it's heart, chroot just changes a process's view of the filesystem. There are still plenty of ways to interfere with the system from inside a chroot jail. I've never used grsecurity, but from the website it's clear that they have substantially improved the feature, i.e. now apache won't be able to break out of that jail.

Is 2.6 really so good without Tux kernel-based webserver and GrSecurity?

grsecurity

LIDS

As far as the NSA planting a back door into SELinux, I really doubt it. A backdoor in open source code would be discovered eventually, and the NSA would have a very hard time denying it.

It seems much more likely that they would put back doors into closed source products, which do not receive as much scrunity.

check out the grsecurity patch for the linux kernel. bundle that with some restrictive iptable rules and i guarantee you'll have a more secure machine than a locked windows box.

The grsecurity patch has a slew of options on masking processes, and it can restrict process execution based on file permissions, stack execution, port creation based on user privledges on the kernel level, and file i/o on the kernel level. all in all, i think this kernel patch puts linux on par with some of the more anal distros like openbsd (although i can't say linux encrypts things as much as openbsd :)

I prefer the GRSecurity patches to LIDS. They contain a lot more than just ACLs.

In the last couple weeks I've amassed a few servers and a client network so, I've had no choice but to become a sysadmin. Which is not what I consider myself (I'm a graphic designer/Web App Programmmer) but, for the sake of responsibility, I find myself fast becoming one.

So I welcome any such article as the one posted here to help better educate me and get me up to date on the even the most mundane of utilities (I hadn't even heard of nessus/netcat)

I'm not a fresh unix convert or technically challenged, it's just that my occupation has demanded that I focus on front end and applicational development rather than network security and monitoring.

So to get by I've been using very basic common sense like running firewalls for port blocking, not running insecure services such as telnet and in the event that i have to (one of my servers is a multiuser webhost so I had to turn FTP on) research and run a more secure variant of that service (for FTP I opted for vsftpd over wu/pro)

And for security, besides my basic IP Masquerading and port blocking firewall (ya, it's that basic, I'm no guru) I run tripwire, which I run a sanity check daily as well as run snort.

This config runs on everyting from my OS X laptop to the RH9 boxes for dev/production serving and seems "ok" for the moment.

I do plan on evaluating/installing some kernal level patches to the RH boxen such as grsecurity but I thought I'd use this topic to fish for pointers as I am also looking for some good educational material such as IP/Network configuration and indepth material on properly setting up an ironclad DMZ. So if anyone has some highly recommended links or knows of soome good books on amazon to point out or even comments to make here to give some pointers, i'd be much appreciative.

The stack/executable bits are there, it's just not that obvious in the feature list. Here's a sample from the news page:

grsecurity 1.9.9f has been released. Changes include RANDEXEC for alpha, sparc, sparc64, and parisc. It also includes KERNEXEC for i386, which implements non-executable and read-only KERNEL pages. To use the feature, you must build a monolithic kernel (that is, CONFIG_MODULES = n). KERNEXEC also makes the IDT, GDT, and syscall table read-only. In addition, stack/mmap randomization has been added for PowerPC, multiple administrators are allowed in the ACL system, and a fix for the ptrace patch discussed on LKML has been included.

It may be a new patch, but I'm not sure why Ingo bothered when grsecurity already does what exec-shield does, and far more.

is this a patch i should have installed on my various linux servers?

Yes. Everyone should have installed grsecurity long time ago for their servers, which provides this protection and much more. It includes ACLs which requires some work to get working, but you don't have to use them. Non-exec stack+heap and address space randomizations require nothing but upgrading the kernel and possibly disabling them for a few binaries that don't like them. I'd guess grsec will include Ingo's patch with it as alternative in future.

Sounds like much of the same security that's been available from grsecurity.net for quite a while now.

I'm sure someone will write a nice nat module for linux/etc to bypass this also

The grsecurity kernel patch already does this

Hi guys.

Just wondering, it seems the OBSD chroot implementation can be broken out of.

I first noticed it here.

And the concept code, which is pretty standard, is here.

Please explain!

Hi guys.

Just wondering, it seems the OBSD chroot implementation can be broken out of.

I first noticed it here.

And the concept code, which is pretty standard, is here.

Please explain!

It CAN support ACL's, with one several patches: grsecurity
which includes PaX.

Check it out!

The exploit doesn't seem to work on every kernel. I've tried two, Gentoo's 2.4.19 and a lightly patched 2.4.20, and only the latter was exploitable.

My best guess is that Grsecurity prevented it from working, or at least changed enough things to stop the standard exploit. It might be worth looking into, to prevent future bugs like this.

HJ Hornbeck

Why not take the SecureOS approach, and run the SMTP listener in a restricted capabilities role, where all your SMTPd can do is "accept()" TCP sessions on port 25, request DNS lookups, and queue messages to disk?

Mandatory Access Control is what you speak of and it's available in several forms for Linux.

GRSecurity
SELinux
(Anyone know of others?)

Just take a look at this wonderful kernel enhancement for Linux.

Moreover is has something on lines of "systrace" from Niels Provos. Basically you create ACLs for what applications may or may not do, including an autolearn-mode.

PS: I know that PaX can be circumvented, but there is much more than PaX included in this project.

PS2: I am aware that parts of this patch is based on SolarDesigner's OWL patches. Although you can get OWL for 2.4 kernels (finally), they lack a lot of the cool protection functions included in grsecurity.

2. Use OSes with better randomisation of IP IDs.

grsecurity can do this for linux.

There are a few kernel patches or custom packages that do this.
StackGuard is one, and GrSecurity is another.

They will break any apps that depend on insecure behavior to function, but said apps can be either fixed or abandoned for alternatives.

grsecurity let's you limit network access to specific uid/gid's. You could in effect make programs setgid 'network' if you want them to be able to access the network and blanket deny the rest of the lot.

Personally, I don't like it when things intended to shock, gross out, or disturb people are posted. Why not some _useful_ sites such as GrSecurity, useful for hardening linux kernels (the ACL system is nice). Incidentally, they just released a new version.

How about APC, a nice open-source free PHP cache. The CVS version is more and more stable each day.

Slashdot is "News For Nerds", not "News for the mentally disturbed". Let's try to keep it to useful/funny topics that are relevant to nerds, geeks, and the like.

Perhaps someone should start SlashWTF.org for news like this.

Its called the grsecurity patch and consists of a whole bunch of seperate security enhancements to the linux 2.4 kernel including randomizing sequence numbers and ttl's.

Be careful though, some of the option change the assumed behavior that other programs rely on. For example kde will not run with some of the options.

The patch in included by default in the gentoo kernel but it is up to the user to enable it. The install docs gives a number of recommondations about which options to enable.

If this is possible, then this would diminish the value of even kernel level ACLs on files and processes. For example, grsecurity and LIDS.

BTW I just followed the instructions listed in another comment in this discussion in order to break out of my own chroot instantly. Wow. :-/ Well at least it's still fine as long as there's no way to gain UID 0 privilege inside a chroot, such as if the network daemon runs as non-UID0 and there are no userspace tools in the chroot.