Recently, most company start use >=2.6.31 kernels to replace redhat kernels.
But the config "Filter access to /dev/mem" is "default n", that allows kernel
rootkit using /dev/mem again. it could access all kernel memory default. Most 
administrator don't known the "Filter access to /dev/mem" is "defult N", when
he compiles the kernel, it's easily to be attacked by rootkit.

Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com> 

---
 arch/x86/Kconfig.debug            |    3 ++-
 arch/x86/configs/i386_defconfig   |    2 +-
 arch/x86/configs/x86_64_defconfig |    2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index bc01e3e..733aea6 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -7,6 +7,7 @@ source "lib/Kconfig.debug"
 
 config STRICT_DEVMEM
 	bool "Filter access to /dev/mem"
+	default y
 	---help---
 	  If this option is disabled, you allow userspace (root) access to all
 	  of memory, including kernel and userspace memory. Accidental
@@ -20,7 +21,7 @@ config STRICT_DEVMEM
 	  This is sufficient for dosemu and X and all common users of
 	  /dev/mem.
 
-	  If in doubt, say Y.
+	  If in doubt, say N.
 
 config X86_VERBOSE_BOOTUP
 	bool "Enable verbose x86 bootup info messages"
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index d28fad1..95c85a8 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -2386,7 +2386,7 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
 # CONFIG_SAMPLES is not set
 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set
-# CONFIG_STRICT_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y
 CONFIG_X86_VERBOSE_BOOTUP=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_EARLY_PRINTK_DBGP=y
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index 6c86acd..659bfe7 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -2360,7 +2360,7 @@ ...
[ message continues ]

Have you ever successfully attack by this way? If CONFIG_STRICT_DEVMEM
--

[ message continues ]

[root@localhost zealot]# ./zealot
[+] Found HISTSIZE.                             [SAFE]
[+] Check md5 values.                           [SAFE]
[+] eth0 was not set promsic.                   [SAFE]
[+] Not found raw socket.                       [SAFE]
system_call addr changed to 0xc04028a0,sys_call_table addr changed to
0xc0675130,Found dr rootkit!,system call sys_execve addr changed to
0xc0401582,system call sys_olduname addr changed to 0xc0405989,system
call sys_fork addr changed to 0xc0407bbb

It's a host ids i wrote,  it could search all kernel memory using /dev/mem. ok?

some of the code here:
static void *kmap(unsigned long off, unsigned long count)
{
        int fd;
        void *p;

        fd = open(DEV_MEM, O_RDWR);
        if (fd < 3) {
                DbgPrint("open %s failed.\n", DEV_MEM);
                dup2(fd, 3);
                close(fd);
                fd = 3;
        }

        p = mmap(NULL, ALIGNUP(count + 4097), PROT_READ | PROT_WRITE,
                MAP_SHARED, fd, ALIGNDOWN(off) & 0x0fffffff);
        if (p == MAP_FAILED)
        {
                mem_support_flag = 1;
                fprintf(stdout, "[-] /dev/mem cannot be read or write.\n");

                DbgPrint("mmap failture, errno %d\n", errno);
                close(fd);
                return NULL;
        }

        close(fd);
        return p;
--

[ message continues ]

Years ago, someone sent the same patch.
--

[ message continues ]

thanks,  i read it.  But nowadays >= 2.6.26 kernel became more
popular, more people start use it.  When they compile the kernel, they
don't change KERNEL_HACKING option, becasue they are not kernel
prgramer.
--

[ message continues ]

mmap_mem in drivers/char/mem.c

        if (!range_is_allowed(vma->vm_pgoff, size))
                return -EPERM;

        if (!phys_mem_access_prot_allowed(file, vma->vm_pgoff, size,
                                                &vma->vm_page_prot))
                return -EINVAL;

If kernel is not set CONFIG_STRICT_DEVMEM, range_is_allowed will
return 1 always, and phys_mem_access_prot_allowed is defined as weak.

In arch/x86/mm/pat.c, phys_mem_access_prot_allowed is defined, and
range_is_allowed is declared to check the mem access w/o
CONFIG_STRICT_DEVMEM, so it looks like the same as kernel w/
CONFIG_STRICT_DEVMEM.

What's the result for kernel w/ CONFIG_STRICT_DEVMEM ? does it prevent
--

[ message continues ]

> I'm curious about the result if you open this option to yes.
here is the result you want see:

Program zealot tried to access /dev/mem between 407000->409000.

my program is not a rootkit, if you want to see some backdoors, please
read the Mood-nt2.3 or suckit source code, have fun.
--

[ message continues ]

If that option doesn't add any protection, what's it good for?
[ message continues ]

Access to /dev/mem being filtered in PAT obviously applies only to x86. 

Architectures which don't do such filtering in their respective 
phys_mem_access_prot_allowed() still need this option.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--

[ message continues ]

So why not use it for all archs uniformly? Is PAT filtering better in
some ways? 


Michal Svoboda

[ message continues ]

On Thu, 15 Apr 2010 15:41:53 +0200

PAT is an x86 specific hardware feature. The x86 processors can set per
page caching properties as with some other CPU designs. In the x86 case
all references to the page must have the same cache settings so the PAT
implementation has to filter /dev/mem access to avoid machine check
errors.

It's not implemented as a security feature, its a side effect of the
hardware requirements on that CPU range.

Alan
--

[ message continues ]

On Thu, 15 Apr 2010 08:36:26 +0200


PAT is x86 specific
--

[ message continues ]

Eek.

So... what is it?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]