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).
The big advantage of Unison on Windows is that it allows quite easily to synchronize between Windows and Linux. For those who need to work on Windows with the same set of files as on Linux, this is a big plus. Other tools do it as well, but the 2-way sync of Unison is quite nice. When you need to compile a software on Linux and Windows, you can modify both side at the same time and (almost) don't have problems.
On Windows, the .unison and unison.log are located into your %HOMEPATH%, which the upper directory of the classic Documents folder. In the directory .unison, you will find the .prf files that describe your unison profiles. As usual, default.prf in this directory is the default profile.
Basic
The basic tips are:
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 Putty which can help you. It has a good support for remote shell but it is not very easy to setup with Unison. Putty and OpenSSH doesn't have precisely the same set of options and Unison relies on some not available in Putty. There is a script called ssh2plink.bat that can help you using Putty's plink as with Unison. I used it for a while, but this didn't give the expected throughput.
The best option is to use the ssh command provided by Cygwin. In this case you have at the same time good throughput and unison integration. I explain here how to configure you Cygwin's ssh to use a SSH key.
You can bypass the following steps, if you wish to use a password or if you have already setup your ssh to connect to the target computer.
Launch Cygwin's setup.exe and select openssh for installation.
To add a SSH key, launch the cygwin shell:
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 
I've just fnished another step for new 
I finally bought myself an eBook reader. To be precise, I got the 
Another week has passed, where is Squeeze? Sadly, I did even less than the week before, but here is the log anyways:
I travel across the Sedgemoor/North Somerset/Bristol council borders, so I m a big fan of 
My blog will move soon to a new URL and software. In fact, I've written my
own static HTML based blog generator, wrapping around Atom for data storage.This is why the feed will also be only available in Atom format in the
future - it works a lot better, and why support 2 formats?The most important feeds are:
Currently, the main product of the Debian project is its stable release
(really this time, not a stupid copy/paste of an old announcement)
Yesterday, 
When talking about free culture or free software, many people suggest
that they would love to support free models, but that they don't see
how to make it all work. Until they have an alternate model in front
of them, they cannot bring themselves to argue for a more ethical
alternative. I disagree with this approach. Instead, I say, "this is
the world I want to live in and, even though I don't know exactly how
to get to there from here, I'm going to refuse to settle for anything
short of this ideal." Most people dismiss such thinking as
"impractical" and "unrealistic." I think most people are being
unimaginative.
I've been trying to work out how to handle (or whether to handle) the vestigial debconf values from emdebian-tools which was replaced in Debian some months ago. I tried to transfer the postrm script to libemdebian-tools-perl which itself is currently a transitional package. Turns out that when debconf tries to purge libemdebian-tools-perl, it doesn't purge the old emdebian-tools settings (it looks for libemdebian-tools-perl.templates instead of emdebian-tools.templates) - unless those were themselves setup by libemdebian-tools-perl. i.e. users with the original emdebian-tools setup will likely have debconf settings that are not purged by removing the package to which those settings should have migrated.
Within the next few days there will be the