Greetings,
After being gloriously rootkitted with a program coded by HTB author Martin
Devera (lots of thanks, devik, your work is appreciated, I suggest you read
up about Oppenheimer when disclaiming that you are 'just a coder'. The item
to google on is: "ethics sweetness hydrogen bomb Oppenheimer"), I wrote
a patch to disable /dev/kmem and /dev/mem, which is harmless on servers
without X.
It blocks attempts by rootkits, such as devik's SucKIT, to hide themselves.
It is not a final solution but it raises the bar a lot. Please apply.
By default, nothing is changed, but I'd turn this feature on on servers
without X. Patch:
--- linux-2.6.0-test1/drivers/char/Kconfig.orig Mon Jul 14 05:29:27 2003
+++ linux-2.6.0-test1/drivers/char/Kconfig Sun Aug 3 19:55:37 2003
@@ -1003,5 +1003,20 @@
out to lunch past a certain margin. It can reboot the system
or merely print a warning.
+config MEMORY_ACCESS
+ bool "Allow userspace access to memory"
+ default y
+ help
+ Security paranoid operators may want to disable userspace
+ from accessing raw memory or kernel memory via /dev/mem and
+ /dev/kmem. Some malware hides itself from sight by manipulating
+ the kernel directly via raw memory, disabling this feature
+ gives some protection against rootkits.
+
+ Answering 'N' generally breaks the X Window System.
+
+ Answer 'Y' unless you are paranoid about security or don't
+ care about X.
+
endmenu
--- linux-2.6.0-test1/drivers/char/mem.c.orig Sun Aug 3 19:22:29 2003
+++ linux-2.6.0-test1/drivers/char/mem.c Sun Aug 3 19:34:04 2003
@@ -608,12 +608,14 @@
static int memory_open(struct inode * inode, struct file * filp)
{
switch (minor(inode->i_rdev)) {
+#if defined(CONFIG_MEMORY_ACCESS)
case 1:
filp->f_op = &mem_fops;
break;
case 2:
filp->f_op = &kmem_fops;
break;
+#endif
case 3:
filp->f_op = &null_fops;
break;
@@ -655,8 +657,10 @@
umode_t mode;
struct file_operations *fops;
} devlist[] = { /* list of minor devices */
+#if defined(CONFIG_MEMORY_ACCESS)
{1, "mem", S_IRUSR | S_IWUSR | S_IRGRP, &mem_fops},
{2, "kmem", S_IRUSR | S_IWUSR | S_IRGRP, &kmem_fops},
+#endif
{3, "null", S_IRUGO | S_IWUGO, &null_fops},
#if defined(CONFIG_ISA) || !defined(__mc68000__)
{4, "port", S_IRUSR | S_IWUSR | S_IRGRP, &port_fops},
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
On Sun, Aug 03, 2003 at 09:11:02PM +0200, Willy Tarreau wrote:
> Why not make this change dynamic instead ? eg : your system boots unlocked,
> and definitely locks /dev/{,k}mem once you do something such as
>
> echo foo > /proc/path_to_magic_entry
I thought about something like that but then for loading modules too - which
would allow for a modular boot but a lock afterwards.
> So the same config can be used with kernel with and without X, it's just a
> matter of runtime configuration. It could even be a sysctl, as long as there's
> no way to unset it.
Well, I fear the runtime overhead - as it is, I suspect this patch is
somewhat inflamatory anyhow ('tough luck you were hacked', 'you are fscked
anyhow').
However, the check would be in {,k}mem_open and in sys_init_module, which
are not heavily used functions.
I'll whip up a dynamic patch soonish - I'm unsure about the right location,
/proc/sys/ something?
Thanks.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
On Sun, Aug 03, 2003 at 08:09:50PM +0200, bert hubert wrote:
> It blocks attempts by rootkits, such as devik's SucKIT, to hide themselves.
>
> It is not a final solution but it raises the bar a lot. Please apply.
>
> By default, nothing is changed, but I'd turn this feature on on servers
> without X. Patch:
Why not make this change dynamic instead ? eg : your system boots unlocked,
and definitely locks /dev/{,k}mem once you do something such as
echo foo > /proc/path_to_magic_entry
So the same config can be used with kernel with and without X, it's just a
matter of runtime configuration. It could even be a sysctl, as long as there's
no way to unset it.
Regards,
Willy
bert hubert <[email protected]> wrote:
>
> +#if defined(CONFIG_MEMORY_ACCESS)
> {1, "mem", S_IRUSR | S_IWUSR | S_IRGRP, &mem_fops},
> {2, "kmem", S_IRUSR | S_IWUSR | S_IRGRP, &kmem_fops},
> +#endif
Well if you're going to do this, wouldn't it be better to force a segv and
drop some messages in syslog?
On Sun, Aug 03, 2003 at 09:18:33PM +0200, bert hubert wrote:
> Well, I fear the runtime overhead - as it is, I suspect this patch is
> somewhat inflamatory anyhow ('tough luck you were hacked', 'you are fscked
> anyhow').
I don't worry about this on opening *mem !
> I'll whip up a dynamic patch soonish - I'm unsure about the right location,
> /proc/sys/ something?
hmmm something such as /proc/sys/kernel/secured ?
You could even implement 3 levels :
- 0 = normal
- 1 = secured, but can go back to 0. At least this stops automated scripts.
- 2 = secured and cannot go back to lower level anyhow.
Cheers,
Willy
On Sun, 3 Aug 2003, bert hubert wrote:
> After being gloriously rootkitted with a program coded by HTB author Martin
> Devera (lots of thanks, devik, your work is appreciated, I suggest you read
> up about Oppenheimer when disclaiming that you are 'just a coder'. The item
> to google on is: "ethics sweetness hydrogen bomb Oppenheimer"), I wrote
> a patch to disable /dev/kmem and /dev/mem, which is harmless on servers
> without X.
For running X when /dev/mem is disabled, a solution can /dev/svga
device, that I wrote for svgalib. It allows mmap access like
/dev/mem, but only for VGA cards related memory - PCI regions that
belong to VGA cards, and 0-0x110000 (for drivers that use the bios).
Of course, depending on the video card and the system, access to the
video card's registers might be equivalent to access to all system
memory, but it does add another layer of security.
See the driver at
http://www.arava.co.il/matan/svgalib/svgalib-1.9.17.tar.gz
--
Matan Ziv-Av. [email protected]
On Sun, Aug 03, 2003 at 12:32:18PM -0700, Andrew Morton wrote:
> bert hubert <[email protected]> wrote:
> >
> > +#if defined(CONFIG_MEMORY_ACCESS)
> > {1, "mem", S_IRUSR | S_IWUSR | S_IRGRP, &mem_fops},
> > {2, "kmem", S_IRUSR | S_IWUSR | S_IRGRP, &kmem_fops},
> > +#endif
>
> Well if you're going to do this, wouldn't it be better to force a segv and
> drop some messages in syslog?
problem with sigsegv is that it does not allow legitimate programs to choose
an alternate approach - the log entry would be nice though.
as one of the 'tastemasters', what are your thoughts on doing this
dynamically? The sigsegv option might be a dynamic option?
Thanks.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
Previously bert hubert wrote:
> problem with sigsegv is that it does not allow legitimate programs to choose
> an alternate approach - the log entry would be nice though.
Is that likely to happen on the kind of machines on which you will use
this option?
Also, if your purpose is to prevent userland from meddling with memory
you might want to block iopl was well.
Wichert.
--
Wichert Akkerman <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
bert hubert <[email protected]> wrote:
>
> as one of the 'tastemasters', what are your thoughts on doing this
> dynamically? The sigsegv option might be a dynamic option?
who, me? umm...
I can see that a patch like this would have a place in a general
security-hardened kernel: one which closes off all the means by which root
can alter the running kernel.
But that's a specialised thing which interested parties can maintain as a
standalone patch, and bringing just one part of it into the main kernel
seems rather arbitrary.
On Sul, 2003-08-03 at 19:09, bert hubert wrote:
> up about Oppenheimer when disclaiming that you are 'just a coder'. The item
> to google on is: "ethics sweetness hydrogen bomb Oppenheimer"), I wrote
> a patch to disable /dev/kmem and /dev/mem, which is harmless on servers
> without X.
You can do this without modifications using the security interface
hooks. If you want to do it right with 2.4 or without security modules
you need to globally revoke CAP_SYS_RAWIO and CAP_SYS_MODULE otherwise
you merely made it harder.
> It blocks attempts by rootkits, such as devik's SucKIT, to hide themselves.
>
> It is not a final solution but it raises the bar a lot. Please apply.
Fine in theory but you can do this via security modules so its better if
you write a security policy module for it.
On Sun Aug 03, 2003 at 08:09:50PM +0200, bert hubert wrote:
> Greetings,
>
> After being gloriously rootkitted with a program coded by HTB author Martin
> Devera (lots of thanks, devik, your work is appreciated, I suggest you read
> up about Oppenheimer when disclaiming that you are 'just a coder'. The item
> to google on is: "ethics sweetness hydrogen bomb Oppenheimer"), I wrote
> a patch to disable /dev/kmem and /dev/mem, which is harmless on servers
> without X.
>
> It blocks attempts by rootkits, such as devik's SucKIT, to hide themselves.
Until the rootkit, already running as root, loads stuff as a
kernel module... Perhaps you should make this enforce that
people have CONFIG_MODULES=n,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Sun, Aug 03, 2003 at 10:26:41PM +0200, Willy Tarreau wrote:
> On Sun, Aug 03, 2003 at 09:18:33PM +0200, bert hubert wrote:
>
> > I'll whip up a dynamic patch soonish - I'm unsure about the right location,
> > /proc/sys/ something?
>
> hmmm something such as /proc/sys/kernel/secured ?
Too generic a name. There are many ways to secure a kernel.
On Sun, 3 Aug 2003, Andrew Morton wrote:
> bert hubert <[email protected]> wrote:
> >
> > as one of the 'tastemasters', what are your thoughts on doing this
> > dynamically? The sigsegv option might be a dynamic option?
>
> who, me? umm...
>
> I can see that a patch like this would have a place in a general
> security-hardened kernel: one which closes off all the means by which root
> can alter the running kernel.
>
> But that's a specialised thing which interested parties can maintain as a
> standalone patch, and bringing just one part of it into the main kernel
> seems rather arbitrary.
why not bring the other parts in as options as well?
I can understand not bringing in all the external security modules that
want to regulate access to everything else (full capabilities, etc) but
locking down the kernel itself to prevent it from being modified seems
like something that would have a place on most servers, possibly also on
desktops that aren't dynamicly adding hardware (probably not that useful
for many laptop users for this reason)
we already have the option to not support modules (as Alan Cox points out
every time that subject comes up it can be bypassed by people who have
access to /dev/*mem) so it would seem that adding the option to bar access
to /dev/*mem as well would make exisitng config options mean what they
appear to mean.
David Lang
On Sun, Aug 03, 2003 at 02:33:01PM -0700, David Lang wrote:
> we already have the option to not support modules (as Alan Cox points out
> every time that subject comes up it can be bypassed by people who have
> access to /dev/*mem) so it would seem that adding the option to bar access
> to /dev/*mem as well would make exisitng config options mean what they
> appear to mean.
This was also on my mind, yes. As Wichert said, not all holes are closed
then, there is also /dev/microcode, iopl() and more.
However, perhaps we could all sweep them under the "don't allow userspace to
touch kernel memory easily" banner?
We can leave more finegrained tools to outside patchsets then.
I think root will always be able to figure out a way to get into the
kernel's innards, but we can raise the bar quite a lot easily without too
much infrastructure.
As to what Alan said about LSM, I've yet to see how to do that in a
reasonable way. But I didn't look too hard.
As to what Andries said, how about '/proc/sys/raw_memory_access'?
Thanks.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
> After being gloriously rootkitted with a program coded by HTB author Martin
> Devera (lots of thanks, devik, your work is appreciated, I suggest you read
> up about Oppenheimer when disclaiming that you are 'just a coder'. The item
> to google on is: "ethics sweetness hydrogen bomb Oppenheimer"), I wrote
Hi,
I feel I should react to this publicaly - however all replies should
be send to me privately as it is off-topic.
SucKIT is NOT written by me - I have no time to do such things. One
time I've been rootkited by older suckit. I was able to track the attacker
down (because he drunk much beer before doing the attack).
I started to chat with him because I wanted to know more about security
especially to be able to safe my servers.
Disabling /dev/{,k}mem was part of it. At this time he asked me what I
think about possibility to change syscall table with no previous
knowledge. I replied with test code which is able to locate syscall table
and kmalloc routine address using some statistics on /dev/kmem.
We made article for Phrack magazine which discovered the posibility
and how to defend itself. It was end of the story for me.
Later I find that some other crackers are using/distribute better
SucKIT and that my name is often displayed on start of rootkited system.
I want to say that I'm not affiliated with SucKIT nor with cracking
and rootkiting of servers. I'll try to convince mentioned hacker
to remove my name from the kit as I'm tired of all the complaints :-(
If you feel that I'm source of your problems then I'm sorry for it.
devik
Erik Andersen wrote:
>bert hubert wrote:
>
>
>>Greetings,
>>
>>
>>It blocks attempts by rootkits, such as devik's SucKIT, to hide themselves.
>>
>>
>
>Until the rootkit, already running as root, loads stuff as a
>kernel module... Perhaps you should make this enforce that
>people have CONFIG_MODULES=n,
>
>
>
(on a diff thread you talked about doing this dynamically)
Maybe you should also disable module loading.
has anyone already done such a thing as disabling module loading after a
point in system startup?
Eliezer
On Sul, 2003-08-03 at 22:47, bert hubert wrote:
> As to what Alan said about LSM, I've yet to see how to do that in a
> reasonable way. But I didn't look too hard.
Just refuse anything needing CAP_SYS_RAWIO at all times. Thats why this
capability flag exists. Or with SELinux you can create a role which has
RAWIO access but is very limited in other ways (eg "Only my X server",
or "only the firmware loader for my serial card") and which is tainted
if anything else touches those files
Alan
On Mon, Aug 04, 2003 at 11:37:57AM +0200, devik wrote:
> think about possibility to change syscall table with no previous
> knowledge. I replied with test code which is able to locate syscall table
> and kmalloc routine address using some statistics on /dev/kmem.
(...)
> I want to say that I'm not affiliated with SucKIT nor with cracking
> and rootkiting of servers. I'll try to convince mentioned hacker
> to remove my name from the kit as I'm tired of all the complaints :-(
>
> If you feel that I'm source of your problems then I'm sorry for it.
Ok - apologies for my needless rant in your direction. I guess I also just
felt bad for not upgrading my kernel in 450 days of uptime, if I did that, I
would not have been rooted in the first place.
Will try to avenge all this by implementing a nice LSM module for preventing
such malware from being able to deploy too easily :-)
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO