Re: Debian Stable server hacked
On Thu, Aug 07, 2003 at 07:03:13PM +0200, Thijs Welman wrote: Hi, Thanks. I forgot to mantion that i am subscribed to debian-security-announce as well (ofcourse ;)). As far as the kernel updates are concerned: i use my own kernel. At this moment that's 2.4.21 with Alan Cox' patches (ac4). Could be there's an exploit in that kernelversion. Maybe i should consider to go back to a debian-packagekernel... Anyone any comment on or experience with debian vs custom kernels? Generally if there is a kernel exploit, it is only used to get root from some other account. The way they get in is though some server app with a hole in it (known or not known). For over 2 years I've been running stable debian with Debian kernel without any problems, well, until someone broke in. So, now I don't run a Debian kernel at all - only a monolithic (no modules) kernel with grsecurity.net patches. Then I set up the ACL system (more or less) so that all of the services that can be used to break into the system are quite useless for the attacker. For example, apache can only execute from paths that it cannot write to. Heck, same for root but apache can't even see /bin, etc.. The only problem was with SSH since if that is compromised, you get root. So I would suggest to only allow selected IPs to access SSH to provent someone from the other side to loggin in. ACLs are a bitch to set up, but then even if an attacker manages to break though an app into into your box, they will not be allowed to do anything :) Well, at least with grsecurity it should be more difficult to compromise a box by a few orders of magnitude.. - Adam PS. Needless to say, I would recommend grsecurity for server machines :)
Re: Debian Stable server hacked
*** REPLY SEPARATOR *** On 12.08.2003 at 23:20 Adam Majer wrote: On Thu, Aug 07, 2003 at 07:03:13PM +0200, Thijs Welman wrote: Hi, Thanks. I forgot to mantion that i am subscribed to debian-security-announce as well (ofcourse ;)). As far as the kernel updates are concerned: i use my own kernel. At this moment that's 2.4.21 with Alan Cox' patches (ac4). Could be there's an exploit in that kernelversion. Maybe i should consider to go back to a debian-packagekernel... Anyone any comment on or experience with debian vs custom kernels? Generally if there is a kernel exploit, it is only used to get root from some other account. The way they get in is though some server app with a hole in it (known or not known). snip This is why my personal favourite it the former trusted debian project, now kown as http://www.adamantix.org. Take a look at their site, they offer RSBAC, PaX, all the goodies for the Kernel AND: They recompile all packages to be buffer overflow proof and as secure as possible. Mixing with standard debian packages is not recommended of course, but so far I haven't encountered any problems. Nearly everything is there if You don't require X anyway. regards Martin
new debian kernel
Hello, using debian kernel 2.4.18-11 on some servers, after ps ax command at the end of input I noticed Segmentation fault message. strace ps ax gave: open(/proc/1048/environ, O_RDONLY)= 7 read(7, unfinished ... +++ killed by SIGSEGV +++ Is it unsuccesfull patch for http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0501 or other problems? Is this patched on 2.4.18-12 ? Regards, Martynas
Re: new debian kernel
Martynas Domarkas [EMAIL PROTECTED] wrote:
Hello, using debian kernel 2.4.18-11 on some servers, after ps ax
command at the end of input I noticed Segmentation fault message.
strace ps ax gave:
open(/proc/1048/environ, O_RDONLY)= 7
read(7, unfinished ...
+++ killed by SIGSEGV +++
Is it unsuccesfull patch for
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0501 or other
problems? Is this patched on 2.4.18-12 ?
Yes it is fixed in kernel-source 2.4.18-13. However, due to another
issue introduced by the security fix, you should download the latest
kernels from http://auric.debian.org/~herbert/.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
methodist
schedule accommodated cricket schoolmaster technical tames scrub mile polarograph maxima pleases cower adumbrated saturated bluish scops cotillion scatter crosswords huh cranelike bombarded exhume terminators coverlet expelled crafted crates andersen polariscope $RANDO MIZE screwbean seater crouched alcestis banbury housetop crowd talus illustrates brainstorm crossing idly plumbed bombast accounted bologna scoreboard polyglot hypochlorous taller actinide addresser brave melodrama scholar tenant bourgeois botulinus costumed cosponsor $RANDOM IZE midshipman boggling boxcars crowder pollock illustrations acknowledges afghanistan bobs pore teachers tensing thematic meteors ewes meeting howls satisfied bluegrass accumulated tempting hyacinth bonding ankara 3rd bounces boatsman borneo portions saucers accost pomade meningitis bombarded housekeep populate agnew plower menstruate teardrop tenable teaspoonful please crook crossarm portrait activated achieved benjamin pompano experimenting $RANDOM IZE illegitimacy admonishments populate acrylic playgrounds microwords meridian anaheim crosswords criminally accordion militia audubon bosoms mayoral adjures acts screwdriver scrapping plodding miff breadbox bonanzas cos boxwood scholarships taught tensional sarcastic seahorse $RANDOMI ZE cropper temerity croquet humidified testy savoy terraced teenagers scream crow admonition thenceforth RANDOMIZE hushes humanoid blenheim postprocessor crossover microjoule teleprinter cribbing
Re: new debian kernel
Yes it is fixed in kernel-source 2.4.18-13. However, due to another issue introduced by the security fix, you should download the latest kernels from http://auric.debian.org/~herbert/. Thanks for your answer. 2.4.18-12 works without segfaults. Is something wrong in 2.4.18-12 more? Is that local or remote exploitable issues? When 2.4.18-13 will be in stable tree of debian? Regards, Martynas
Re: Debian Stable server hacked
On Wed, 2003-08-13 at 00:20, Adam Majer wrote: So, now I don't run a Debian kernel at all - only a monolithic (no modules) kernel with grsecurity.net patches. Then I set up the ACL system (more or less) so that all of the services that can be used to break into the system are quite useless for the attacker. For example, apache can only execute from paths that it cannot write to. Heck, same for root but apache can't even see /bin, etc.. I admit to not having investigated grsecurity very much. But one question that comes up occasionally on the SELinux list and on IRC is How do I hide files/directories from a process, or prevent it from executing them?. The answer for the former is that with SELinux you can't reliably hide things, and although you can prevent execution of normal binaries such as stuff in /bin, it's not widely used. For example, regular users have permission to execute /bin/mount. Why? Because SELinux doesn't solely associate security with executable pathnames. If someone takes over control of the apache process via a buffer overflow or whatever, they don't need /bin/ls to list a directory; they can just as easily use the opendir/readdir/stat system calls. Likewise, they don't need /bin/mount to mount filesystems; they can just as easily use the mount syscalls. So the whole grsecurity ACL system seems very weak in that respect. Let me give an example of how SELinux protects my machine (verbum.org). My blog is a Python script (pyblosxom) which runs in a domain called httpd_user_script_t. This domain can execute programs such as /bin/sh (I think pyblosxom might use system() in a place or two). Suppose an attacker somehow got pyblosxom to execute arbitrary commands to /bin/sh. With SELinux, that doesn't help an attacker at all, because the new /bin/sh process gets the same security context as the CGI script, so it doesn't have any more privileges. The security is at the level of the system calls it can make, not what binaries it can execute.
Re: Debian Stable server hacked
On Wed, Aug 13, 2003 at 04:02:41PM -0400, Colin Walters wrote: Why? Because SELinux doesn't solely associate security with executable pathnames. If someone takes over control of the apache process via a buffer overflow or whatever, they don't need /bin/ls to list a directory; they can just as easily use the opendir/readdir/stat system calls. Likewise, they don't need /bin/mount to mount filesystems; they can just as easily use the mount syscalls. So the whole grsecurity ACL system seems very weak in that respect. grsec handles this by allowing you to restrict Linux capabilities for a process. For example, there's no reason /usr/sbin/apache should have access to CAP_SYS_ADMIN (allows mount/umount, amongst other things) or CAP_SYS_PTRACE (run ptrace) or many others. Anyway, since grsec uses PaX, it's very unlikely that anyone will take control of apache through a buffer overflow. ;-)
Re: Debian Stable server hacked
On Wed, 2003-08-13 at 18:39, valerian wrote: grsec handles this by allowing you to restrict Linux capabilities for a process. For example, there's no reason /usr/sbin/apache should have access to CAP_SYS_ADMIN (allows mount/umount, amongst other things) or CAP_SYS_PTRACE (run ptrace) or many others. But Linux capabilities are so weak. They won't protect an apache master process that runs as root from scribbling over /etc/passwd and giving an attacker a new uid 0 shell account, for example. At that point it's really game over. The attacker then logs in, and has all the capabilities. From there, they have access to /dev/mem, where they can runtime patch the kernel and kill off grsecurity or do whatever else they want. Anyway, since grsec uses PaX, it's very unlikely that anyone will take control of apache through a buffer overflow. ;-) From what I understand it is often possible to evade these kinds of restrictions. Anyways, I just wanted to point out that while grsecurity probably helps somewhat, it provides significantly less security than a system like SELinux. Its sole advantage as far as I can tell is that it's somewhat easier to set up.
Re: Debian Stable server hacked
On Wed, Aug 13, 2003 at 07:08:59PM -0400, Colin Walters wrote: But Linux capabilities are so weak. They won't protect an apache master process that runs as root from scribbling over /etc/passwd and giving an attacker a new uid 0 shell account, for example. At that point it's really game over. The attacker then logs in, and has all the capabilities. From there, they have access to /dev/mem, where they can runtime patch the kernel and kill off grsecurity or do whatever else they want. Well capabilities are only one of the things that grsec implements. You can also restrict a process to access various parts of the filesystem. There's no reason /usr/sbin/apache should have write access to /etc, so you just don't allow it. You can also place restrictions based on resources (cpu, memory, etc.) and IP addresses as well. BTW, grsec (well gradm actually) has an intelligent self-learning mode that can help you to give a process only the minimum amount of access necessary to operate in. That way, even a novice sysadmin should be able to benefit from a higher level of security. And even for experienced sysadmins, it makes the process of setting up ACLs much less error-prone. Anyway, since grsec uses PaX, it's very unlikely that anyone will take control of apache through a buffer overflow. ;-) From what I understand it is often possible to evade these kinds of restrictions. It actually does a very good job of stopping any kind of stack-smashing attack dead in its tracks (both the stack and heap are marked as non-executable). That takes care of most vulnerabilities, both known and unknown. Anyways, I just wanted to point out that while grsecurity probably helps somewhat, it provides significantly less security than a system like SELinux. Its sole advantage as far as I can tell is that it's somewhat easier to set up. Why even jump to conclusions like this when you admitted a few messages back that you don't know much about grsec? ;-(
