uncompiled.com

Con Kolivas had stopped working on the Linux kernel for two years after he became fed up with the kernel development community, but last year he made a return by introducing the BFS scheduler. The BFS scheduler for the Linux kernel is quite simple in design compared to other schedulers, but it performed fairly well on desktop systems. Due to Con’s past frustrations, he has no intentions of mainlining the Brain Fuck Scheduler, but he has now offered up another batch of patches.

Kolivas has released a new set of patches this morning that are “designed to improve system responsiveness and interactivity with specific emphasis on the desktop.” There are 13 patches he has made available that can be applied against the freshly released Linux 2.6.33 kernel. One of the patches is BFS, another changes the default timer frequency to 1000Hz, another adds new values that allows the timer frequency to be upped to 10,000Hz, and various other changes.

While Con Kolivas is not likely trying to get these patches pushed into the Linux 2.6.34 kernel, he has published this to the Linux kernel mailing list. His patches can be found in the 2.6.33-ck1 directory.

Source

According to a study by researchers at the University of Oviedo (Universidad de Oviedo) in Spain, the estimated total value of the 2.6.30 Linux kernel, released in June of 2009, is more than €1 billion. Using the kernel development history from version 2.6.11 to 2.6.30, the researchers calculated the costs by using the Constructive Cost Model 81 (COCOMO 81) and taking the average annual salary for a developer in 2006 in the European Union as a parameter. According to EUROSTAT, that was approximately €31,000. The Linux Foundation published a similar study in October of 2008.

The COCOMO algorithm calculates the value of software using a number of specific metrics, specifically the number of lines of code written. The study looks at the estimated annual research and development (R&D) costs of the kernel releases and shows that the annual Linux kernel R&D cost increased significantly in 2008. Between 2005 and 2006, annual R&D was estimated at between €72 to €94 million, however, in 2008, that number rose to more than €228 million.

The two researchers responsible for the study, Jesús García-García and Mª Isabel Alonso de Magdaleno, will be be presenting their findings at the Concord 2010 conference on corporate R&D taking place on the 3rd and 4th of March, 2010 in Seville, Spain.

Source

Hi Dave & list:

I’m writing to report a bug in recent vanilla kernels regarding the
ability to execute in non-executable pages on SPARC. I’m no SPARC
expert, but I’ll try to explain as best I can the problem and make
myself available for debugging/testing any fixes.

I have 4 sparc systems currently, a Netra T1, an Ultra 10, a Sunfire
V210, and a Blade 2500. The first two systems run the latest 2.4
kernels and experience no problems. The second two systems run recent
2.6 kernels (2.6.31 and 2.6.32) and both utilize the Cheetah+ MMU. Both
of these systems running the recent 2.6 kernels exhibit the problem.

I’ve provided two simple testcases that illustrate the problem. Either
run them in a loop or just multiple times — eventually instead of
receiving a segfault (as it should every time for attempting to execute
on the stack, which is non-executable by default per ABI) the shellcode
I’ve set up on the stack will execute without problems. In the first
testcase I haven’t set up enough code to perform a return from the
function pointer, so you see the varied signals when an instruction
fetch is attempted on the 2nd instruction (made up of whatever
happened to be located on the stack). In the second case I set up the
proper ret/restore and the program is able to exit cleanly.

I’m willing to do anything to help debug the problem, but I thought it
would
be wiser to report it first in case anyone had any immediate ideas on
what the problem could be. I figured it would also help in being able
to debug the issue more effectively, given its seemingly somewhat-random
nature.

Please keep the PaX team and myself CC’d as we’re not subscribed to the
list.

Thanks for your help,
-Brad

cat /proc/self/maps output (showing the stack non-executable):
00010000-00014000 r-xp 00000000 08:02 1769474 /bin/cat
00024000-00026000 rwxp 00004000 08:02 1769474 /bin/cat
00026000-00048000 rwxp 00000000 00:00 0 [heap]
f7cf0000-f7e2a000 r–p 00000000 08:02 295830 /usr/lib/locale/locale-archive
f7e2c000-f7fa4000 r-xp 00000000 08:02 1277958 /lib/ultra3/libc-2.7.so
f7fa4000-f7fb4000 —p 00178000 08:02 1277958 /lib/ultra3/libc-2.7.so
f7fb4000-f7fba000 rwxp 00178000 08:02 1277958 /lib/ultra3/libc-2.7.so
f7fba000-f7fbc000 rwxp 00000000 00:00 0
f7fbc000-f7fde000 r-xp 00000000 08:02 1270085 /lib/ld-2.7.so
f7fec000-f7ff0000 rwxp 00020000 08:02 1270085 /lib/ld-2.7.so
f7ff0000-f7ff2000 rw-p 00000000 00:00 0
ffdb6000-ffde0000 rw-p 00000000 00:00 0 [stack]

First test case:
#include

typedef int (* _wee)(void);

int main(void)
{
char buf[4] = { ‘\x81′, ‘\xc7′, ‘\xe0′, ‘\x08′};
_wee wee;
printf(“%p\n”, &buf);
wee = (_wee)&buf;
wee();

return 0;
}

gdb output in 90-95% of the cases:
Program received signal SIGSEGV, Segmentation fault.
0xff9d9cb0 in ?? ()

gdb output in the other 5-10% of cases:
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/test
0xff811cb0

Program received signal SIGBUS, Bus error.
0xff811cb4 in ?? ()
(gdb) x/x 0xff811cb0
0xff811cb0: 0×81c7e008
(gdb) x/i 0xff811cb0
0xff811cb0: ret
0xff811cb4: lda [ %g4 + %l0 ] (229), %f31

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/test
0xff97dcb0

Program received signal SIGILL, Illegal instruction.
0xff97dcb4 in ?? ()
(gdb) x/8x $pc-4
0xff97dcb0: 0×81c7e008 0xff97dcb0 0xf7f3af00
0×00000000
0xff97dcc0: 0×00000000 0×00000000 0xfffffffc
0×00000000
(gdb) x/i $pc-4
0xff97dcb0: ret
0xff97dcb4: ldqa [ %i7 + %l0 ] (229), %f62

modified code so it executed a ret / restore:
#include

typedef int (* _wee)(void);

int main(void)
{
char buf[8] = { ‘\x81′, ‘\xc7′, ‘\xe0′, ‘\x08′, ‘\x81′, ‘\xe8′,
‘\x00′, ‘\x00′ };
_wee wee;
printf(“%p\n”, &buf);
wee = (_wee)&buf;
wee();

return 0;
}

gdb output in the 5-10% case:
Starting program: /root/test
0xffb4fca8

Program exited with code 01.

Source

A report has been received from Juniper at 4:25pm under bulletin PSN-2010-01-623 that a crafted malformed TCP field option in the TCP header of a packet will cause the JUNOS kernel to core (crash). In other words the kernel on the network device (gateway router) will crash and reboot if a packet containing this crafted option is received on a listening TCP port. The JUNOS firewall filter is unable to filter a TCP packet with this issue. Juniper claims this issue as exploit was identified during investigation of a vendor interoperability issue.

Source

If you were sat at your Linux computer one dark evening in late 1999, things would have been considerably different. Your machine would probably be running either Red Hat 6.1 or Mandrake 6. Outside your window, the world was going crazy for all things dotcom. Microsoft was prepping both Windows 2000 and its ill-fated Millennium edition, while Apple had just released OS 9 and its Power Mac G4.

As a Linux user, you’d have been an uber-geek, someone with an obsessive interest in computing and far too much time on your hands. But things have changed. Linux is now an operating system anyone can install and use, and it’s growing stronger every year. Here’s how it happened.

Source

Brad Spengler noted on Twitter today:

Cool, the Chrome OS docs recommend applying grsec: http://bit.ly/26p2ac (has other hardening tips that apply to any Linux system too)

From the document:

Efforts to secure Linux environments tend to revolve around the principle of least privilege and applying exploit mitigation tactics wherever possible. While the exploit mitigation techniques are effective, they are never a perfect defense and often the specific techniques deployed vary from distribution to distribution. In addition, the principle of least privilege is excellent in a server environment and for locking down system services on desktops. However, desktop systems are meant to be general purpose. This makes it incredibly difficult to determine the least privilege needed if a program has not ever been seen on the system before (or was written since the system was installed!). The end result is that the risks from interactively executed applications are addressed only using exploit mitigations and not as comprehensively as desired.

Chromium OS has an advantage. All native programs run by the end user are known in advance since all general purpose applications are web applications. We use this knowledge to apply comprehensive access control enforcement in addition to the well-known exploit mitigation techniques. This combination allows Chromium OS to benefit from the great work securing Linux in both end-user and server enviroments!

Source

Microsoft has reportedly begun investigating a potentially nasty denial of service vulnerability affecting Windows 7.

A security bug in windows 7 and Windows 2008R2 makes it possible to lock up affected systems. The crash would happen without a Blue Screen of Death or other visible indication that anything was amiss.

The system freeze can be triggered remotely by sending malformed packets to targeted systems – specifically a NetBIOS (Network Basic Input/Output System) header that specifies an incoming SMB packet is either four bytes smaller or larger than it actually is. Server Message Block (SMB) is a network protocol used to provide shared access to files and printers.

Proof of concept code was posted by white hat security researcher Laurent Gaffié in a blog entry on Wednesday. “Whatever your firewall is set to, you can get remotely smashed via IE or even via some broadcasting nbns tricks, [with] no user interaction,” Gaffié writes.

Source

For those who were not yet aware, there is at least 3 public exploits since 11/05/2009 for CVE-2009-3547 targeting *all* linux kernels from 2.6.0 to 2.6.31 included. Since spender and fotis have already release their own, there is not need for us to keep this on our hd.

ImpelDown.c is a poc trying to exploit null ptr dereference in fs/pipe.c for *all* linux kernel from 2.6.0 to 2.6.31 and ImpelDown-2.6.31only.c target only linux kernel version 2.6.31 (tested and approuved with mmap_min_addr at 0).

If you were writing your own, you have already noticed that there is a subtle difference in the way you can own kernels 2.6.0 up to 2.6.10 and kernels 2.6.11 up to 2.6.31: in the first one the null ptr deref leads to an arbitrary write to everywhere in the kernel since you have control over the destination address of

linux2.6.9/fs/pipe.c

…
219 if (pipe_iov_copy_from_user(pipebuf, iov, chars)) {
…
In such case, we try to exploit this by overwriting and old and obsolete syscall address in the sys_call_table by our privilege escalator function address (hehe old school trickz are always the best).

In kernels 2.6.11 up to 2.6.31, exploitation simply resume in mapping the correct struct pipe_inode_info at NULL and the kernel will call a fptr under our control at inode->i_pipe->bufs[1-16].ops->something()

You can find exploits at http://www.vxhell.org/~teach/exploits/ImpelDown.c and http://www.vxhell.org/~teach/exploits/ImpelDown-2.6.31only.c. The first one wasn’t tested but the second would work for the given kernel (according to your mmap_min_addr)

Source

A null pointer dereference in the Linux kernel can be exploited to access a system at root privilege level. The hole is reportedly contained in pipe.c and can occur in certain circumstances when using the pipe_read_open(), pipe_write_open() or pipe_rdwr_open() functions while releasing a mutex (mutual exclusion) too early – which constitutes a classic race condition. So far, the flaw has only been fixed in release candidate 6 of the forthcoming version 2.6.32.

However, like previous null pointer dereference issues in the Linux kernel, the vulnerability can only be exploited if the kernel’s mmap_min_addr system variable is set to 0. mmap_min_addr describes the lowest virtual address a process can use for mapping. If it is greater than 0, exploits that involve a null-valued pointer to this address won’t work. However, as this will also cause certain open source applications like Wine and DOSEMU to malfunction, distributors such as Red Hat and Debian set the respective value to 0 by default. Red Hat has already released updated packages to close the hole. Debian offers instructions on how to change the variable. In Ubuntu, mmap_min_addr is set to 65535, which renders exploits ineffective.

Source

From Brad Spengler’s Twitter

MooseCox released in enlightenment: http://bit.ly/dEtOG complete with OpenBSD history lesson and a picture in the post-exploit payload

This was referenced earlier in Bug in latest Linux gives untrusted users root access