If you re running a 64bit system, and you ve got users with access to a video device (
/dev/video*), then be sure you update your kernels for
CVE-2010-2963. I ve been slowly making my way through auditing the many uses in the Linux kernel of the
copy_from_user() function, and ran into this vulnerability.
Here s the kernel code from
drivers/media/video/v4l2-compat-ioctl32.c:
static int get_microcode32(struct video_code *kp, struct video_code32 __user *up)
if (!access_ok(VERIFY_READ, up, sizeof(struct video_code32))
copy_from_user(kp->loadwhat, up->loadwhat, sizeof(up->loadwhat))
get_user(kp->datasize, &up->datasize)
copy_from_user(kp->data, up->data, up->datasize))
return -EFAULT;
return 0;
Note that
kp->data is being used as the target for
up->data in the final
copy_from_user() without actually verifying that
kp->data is pointing anywhere safe. Here s the caller of
get_microcode32:
static long do_video_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
union
struct video_tuner vt;
struct video_code vc;
...
karg;
void __user *up = compat_ptr(arg);
...
switch (cmd)
...
case VIDIOCSMICROCODE:
err = get_microcode32(&karg.vc, up);
...
So, the contents of
up are totally under control of the caller, and the contents of
karg (in our case, the
video_code structure) are
not initialized at all. So, it seems like a call for
VIDIOCSMICROCODE would write
video_code->datasize bytes from
video_code->data into some random kernel address, just causing an Oops, since we don t control what is on the kernel s stack.
But wait, who says we can t control the contents of the kernel s stack? In fact, this compat function makes it extremely easy. Let s look back at the union. Notice the
struct video_tuner? That gets populated from the caller s
up memory via this case of the
switch (cmd) statement:
...
case VIDIOCSTUNER:
case VIDIOCGTUNER:
err = get_video_tuner32(&karg.vt, up);
...
So, to control the kernel stack, we just need to call this
ioctl twice in a row: once to populate the stack via
VIDIOCSTUNER with the contents we want (including the future address for
video_code->data, which starts at the same location as
video_tuner->name[20]), and then again with
VIDIOCSMICROCODE.
Tricks involved here are: the definition of the
VIDIOCSMICROCODE case in the kernel is wrong, and calling the
ioctls without any preparation can trigger other kernel work (memory faults, etc) that may destroy the stack contents. First, we need the real value for the desired case statement. This turns out to be 0 4020761b. Next, we just repeatedly call the setup
ioctl in an attempt to get incidental kernel work out of the way so that our last
ioctl doing the stack preparation will stick, and then we call the buggy
ioctl to trigger the vulnerability.
Since the ioctl already does a multi-byte copy, we can now copy arbitrary lengths of bytes into kernel memory. One method of turning an arbitrary kernel memory write into a privilege escalation is to overwrite a kernel function pointer, and trigger that function. Based on the
exploit for CVE-2010-3081, I opted to overwrite the
security_ops function pointer table. Their use of
msg_queue_msgctl wasn t very good for the general case since it s near the end of the table and its offset would depend on kernel versions. Initially I opted for
getcap, but in the end used
ptrace_traceme, both of which are very near the top the
security_ops structure. (Though I need share credit here with
Dan Rosenberg as we were working together on improving the reliability of the
security_ops overwrite method. He used the same approach for his excellent
RDS exploit.)
Here are the steps for one way of taking an arbitrary kernel memory write and turning it into a root escalation:
- overwrite
security_ops with default_security_ops, which will revert the LSM back to the capabilities-only security operations. This, however, means we can calculate where cap_ptrace_traceme is.
- overwrite
default_security_ops->ptrace_traceme to point to our supplied function that will actually perform the privilege escalation (thanks to Brad Spengler for his code from Enlightenment).
- trigger the function (in this case, call
ptrace(PTRACE_TRACEME, 0, NULL, NULL)).
- restore
default_security_ops->ptrace_traceme to point to cap_ptrace_traceme so the next caller doesn t Oops the system (since userspace memory will be remapped).
Here s the
source for
Vyakarana as seen
running in Enlightenment using
cap_getcap (which is pretty unstable, so you might want to switch it to use
ptrace_traceme), and as a
stand-alone memory writer.
Conclusions: Keep auditing the kernel for more arbitrary writes; I think there are still many left. Reduce the exploitation surface within the kernel itself (which
PaX and grsecurity have been doing for a while now), specifically:
- Block userspace memory access while in kernel mode. This would stop the ability to make the kernel start executing functions that live in userspace a clear privilege violation. This protection would stop the current exploit above, but the exploit could be adjusted to use kernel memory instead.
- Keep function pointers read-only. There is no reason for these function pointer tables (
fops, IDT, security_ops, etc) to be writable. These should all be marked correctly, with inline code exceptions being made for updating the global pointers to those tables, leaving the pointer read-only after it gets set. This would stop this particular exploit above, but there are still plenty more targets.
- Randomize the kernel stack location on a per-syscall basis. This will stop exploits that depend on a stable kernel stack location (as this exploit does).
So, I m (almost) back from the first edition of MiniDebConf Paris, which was a success thanks to the great organizing skills in panic mode of Carl Chenet and Mehdi Dogguy. I think that everybody is already looking forward to the next edition.
I met lots of people, and it was great to be able to finally put faces on names from the french free software community. I gave two talk there, the first one on Debian and Ubuntu (slides), the second one on Debian Quality Assurance (slides), which both went well (I think).
I also hacked a bit:
There is something fishy with the latest "printer bomb" reports.
One one hand, they claim the parcels were adressed to "jewish synagogues
in Chicago". On the other hand, they claim they were meant to explode in the
air.
So: why would you address them to a synagogue then? Sending a parcel from
Jemen to a synagogue probably is a sure thing to have it thoroughly
checked?
I don't trust any of their reports. Don't get me wrong; for example I do
not believe the WTC was blown up using explosives like most of the conspiration
theorists out there do. But they are not telling the truth with these parcels,
either.
Also given that they claimed there were way over 20 parcels sent, and the
security was that weak, how come all of them were found?
When they decide to make up a story for us (either for having a reason to
kill more people in Jemen or just for election reasons) they should at least
bother to make up a consistent story ...
It turns out that pdfedit is pretty good at extracting text from pdf
files. Here is a script I wrote to do that in batch mode.
OK, I still have to load my photos of Debconf10 somewhere. Shame on
me. My gallery is broken (no longer allows uploads, even local ones!).
Still, do you remember that we somehow mentioned that a small bunch of
geeks did run together a local race at Debconf10?
Indeed, a dozen of Debconf10 attendees did participate to the Van
Cortland Track Club Summer Series run of Thursday August 5th. And all
of us completed this 5km cross-country run in Van Cortland Park, in
Bronx, turning it into the most international attendance of this local
race.
Two kids, their really busy mother and my paid job leave me without much time
to blog or do Debian related work lately (well, at least on my free time,
I do Debian related things at work, but mostly as a user, not as a developer).
Anyway, a couple of weeks ago I decided it was time to upgrade my home servers
to Squeeze and I did it, but it was harder than expected.
At home I'm using two old laptops as servers, an old Aluminium PowerBook and
an Asus EeePC; the Asus was installed to replace an older PowerBook (a really
old one, BTW) that I was using as home server since my father gave it to me.
The plan was to use 
Sunday. A good day to take some time to myself, and get some much needed excercise. And the pseudo-meditation that comes with it: That's one of the factors I love the most about cycling. It's possibly my favorite way of just idling, of allowing for the time to pass without me noticing, just watching the movie of life, watching the world go around me with very little effort. I just love cycling.
I have posted here several mentions of the Ciclot n: Every month, the last Sunday, our city government closes a ~32Km circuit to make it for cycling (and skating, and walking, and jogging, and other human-powered locomotion) use. Whenever I am in the city and have the possibility, I do the Ciclot n. Two months ago, I even did it twice in a row, for a total of almost 70Km.
But this Sunday was not the last Sunday of the month! So, why am I writing this? Well, because when I left home today at ~10AM, I thought it was. Only when I reached Circuito Interior and had a this is full of cars moment, I remembered October has 31 days. And next Sunday I'll very probably be in Oaxaca city (for the 
One big change in the recent 
While I have spent countless hours working on the new source format known as 3.0 (quilt) , I ve just realized that I have never blogged about its features and the reasons that lead me to work on it. Let s fix this.
The good old 1.0 format
Up to 2008, dpkg-source was only able to cope with a single source format (now named 1.0 ). That format was used since the inception of the project. While it worked fine for most cases, it suffered from a number of limitations mainly because it stored the Debian packaging files as a patch to apply on top of the upstream source tarball.
This patch can have two functions: creating the required files in the debian sub-directory and applying changes to the upstream sources. Over time, if the maintainer made several modifications to the upstream source code, they would end up entangled (and undocumented) in this single patch. In order to solve this problem, patch systems were created (dpatch, quilt, simple-patchsys, dbs, ) and many maintainers started using them. Each implementation is slightly different but the basic principle is always the same: store the upstream changes as multiple patches in the 
I recently uploaded new upstream versions of two neat small X tools to
You can also disable virus live scan -- if you think it is safe!!!!
SSH
Using ssh under Windows is always a challenge. As a matter of fact, this tool doesn't match Windows context and it is not as integrated as in Linux/BSD.
There is 
I like to think that in the Ubuntu project, we re pragmatic about technology. This means keeping an open mind, considering alternatives, and evaluating them objectively. It means bearing in mind the needs of the user, and measuring ourselves based on how well we solve their problems (not merely our own).
It is in this spirit that I have been thinking about 
