15 Aug
2009
15 Aug
'09
6:56 a.m.
Hi,
There's a local->root privilege escalation exploit in almost all
versions of the Linux kernel:
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html
https://bugzilla.redhat.com/show_bug.cgi?id=516949
https://bugs.launchpad.net/fedora/+source/linux/+bug/413656
i.e. on affected kernels a local unprivileged user can become root.
Therefore I suggest that you check your distributions for the
relevant security update or else investigate the workarounds. I
have seen an updated kernel package hit Debian lenny.
If you are still on an old VPS setup where you don't have control
over your kernel then please contact support(a)bitfolk.com to get that
sorted out.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
"Xandros's low-level support for the Eee mostly seemed to consist of a pile of
shell scripts made of cheese and failure." -- Matthew Garrett
15 Aug
15 Aug
9:26 a.m.
Hello,
On Sat, Aug 15, 2009 at 06:56:20AM +0000, Andy Smith wrote:
Therefore I suggest that you check your distributions
for the
relevant security update or else investigate the workarounds. I
have seen an updated kernel package hit Debian lenny.
Don't forget that you need to shut down and boot again from xen
shell in order to get a new kernel; just rebooting uses the same
kernel again.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
19 Aug
19 Aug
7:08 a.m.
On Sat, 15 Aug 2009 06:56:20 +0000, Andy Smith <andy(a)bitfolk.com> wrote:
Therefore I suggest that you check your distributions
for the
relevant security update or else investigate the workarounds. I
have seen an updated kernel package hit Debian lenny.
Hello,
The Ubuntu developers have released patches to fix this flaw:
http://www.ubuntu.com/usn/usn-819-1
Despite the mitigation (via mmap_min_addr, see above) it is still
recommended that all users install the kernel update as soon as possible.
Cheers,
David Bell
11:15 a.m.
On 15 Aug 2009, at 10:26, Andy Smith wrote:
Hello,
On Sat, Aug 15, 2009 at 06:56:20AM +0000, Andy Smith wrote:
Why is this? I thought that, at least on Ubuntu a 'shutdown -r' picks
up the latest kernel?!
Also, I'm having this issue on two of the VPS' running Ubuntu at the
moment:
----
The following packages will be upgraded:
libcurl3-gnutls linux-image-2.6.24-24-xen linux-libc-dev
3 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 19.7MB of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n/?] y
Writing extended state information... Done
Get:1 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:2 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:3 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:4 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:5 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:6 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:7 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:8 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:9 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:10 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:11 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:12 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
Get:13 http://apt-cacher.lon.bitfolk.com hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
45% [13 linux-image-2.6.24-24-xen 8967518/18.8MB 47%]
----
Both of them are stuck around 45% download...
Any ideas?
Thanks!!
/Jocke
Therefore I suggest that you check your
distributions for the
relevant security update or else investigate the workarounds. I
have seen an updated kernel package hit Debian lenny.
Don't forget that you need to shut down and boot again from xen
shell in order to get a new kernel; just rebooting uses the same
kernel again.
12:15 p.m.
Hi Jocke,
On Wed, Aug 19, 2009 at 12:15:53PM +0100, Jocke Selin wrote:
On 15 Aug 2009, at 10:26, Andy Smith wrote:
On a normal machine with grub, a reboot gets you to the point where
the BIOS runs grub and grub gets kernel, initrd, etc.
On a Xen domU with pygrub, on domain creation pygrub runs in dom0
(the host server) to read your filesystem, extract your grub config
file, parse it to find the kernel, initrd etc., extract *those* to
a temporary directory and then create a domU with those files.
But on a reboot, Xen never actually destroys the virtual machine, it
just starts it again. That means it will have the same kernel
(pygrub is never run), same amount of RAM, most probably the same
size disk devices as well (I have never tested that bit).
Don't forget that you need to shut down and
boot again from xen
shell in order to get a new kernel; just rebooting uses the same
kernel again.
Why is this? I thought that, at least on Ubuntu a 'shutdown -r' picks up
the latest kernel?! Also, I'm having this issue on two of the VPS'
running Ubuntu at the
moment:
[...]
Get:13 http://apt-cacher.lon.bitfolk.com
hardy-updates/universe linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
45% [13 linux-image-2.6.24-24-xen 8967518/18.8MB 47%]
----
Both of them are stuck around 45% download...
The apt-cacher will proxy a connection to the real Ubuntu mirrors if
it doesn't have the file locally, so it could be that the mirrors
are overloaded.
Is it still happening?
Can you try other mirrors (change the part of the URL that is the
mirror hostname)?
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
"Reinventing the wheel is bad not only because it wastes time, but because
reinvented wheels are often square." -- Henry Spencer
12:39 p.m.
Andy, everybody,
On 19 Aug 2009, at 13:15, Andy Smith wrote:
Righto - I didn't realise that it fetches the files "real time" for
the first time. Quite natural now when mentioned.
On Wed, Aug 19, 2009 at 12:15:53PM +0100, Jocke Selin
wrote:
Thanks for explaining! I'm very new to, but intrigued by, VPS'. :)
So, a shutdown -h in terminal and then a power-up in Zen console. Check!
On 15 Aug 2009, at 10:26, Andy Smith wrote:
On a normal machine with grub, a reboot gets you to the point where
the BIOS runs grub and grub gets kernel, initrd, etc.
On a Xen domU with pygrub, on domain creation pygrub runs in dom0
(the host server) to read your filesystem, extract your grub config
file, parse it to find the kernel, initrd etc., extract *those* to
a temporary directory and then create a domU with those files.
But on a reboot, Xen never actually destroys the virtual machine, it
just starts it again. That means it will have the same kernel
(pygrub is never run), same amount of RAM, most probably the same
size disk devices as well (I have never tested that bit). Don't forget that you need to shut down and
boot again from xen
shell in order to get a new kernel; just rebooting uses the same
kernel again.
Why is this? I thought that, at least on Ubuntu a 'shutdown -r'
picks up
the latest kernel?! Get:13
http://apt-cacher.lon.bitfolk.com hardy-updates/universe
linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
45% [13 linux-image-2.6.24-24-xen 8967518/18.8MB 47%]
----
Both of them are stuck around 45% download...
The apt-cacher will proxy a connection to the real Ubuntu mirrors if
it doesn't have the file locally, so it could be that the mirrors
are overloaded. Is it still happening?
As of a few seconds ago, yes. Still happening.
My unqualified guess would be that this file has been half-downloaded
by the cacher..?!
Can you try other mirrors (change the part of the URL
that is the
mirror hostname)?
Such as to http://gb.archive.ubuntu.com/ instead of http://apt-cacher.lon.bitfolk.com
?
I can yes. I am, however, a bit reluctant to mess with live servers.
If it's what it takes to get things going, then naturally I'm up for it.
Cheers,
/Jocke
1:21 p.m.
Hi Jocke,
On Wed, Aug 19, 2009 at 01:39:45PM +0100, Jocke Selin wrote:
Righto - I didn't realise that it fetches the files "real time" for the
first time. Quite natural now when mentioned.
Okay. Can you try first an "apt-get update" and try it again?
I think it *is* some problem with apt-cache because it seems to have
first downloaded that package at 0741Z today. I've nuked its cache
now; it should proxy it again when someone asks for it.
In general the apt-cache URLs look like:
http://apt-cacher.lon.bitfolk.com/ubuntu/gb.archive.ubuntu.com/ubuntu/
The part after the first "ubuntu/" is the source mirror and path
that apt-cache will use if it doesn't have the file. Allowed hosts
for the Ubuntu apt-cacher are:
archive.ubuntu.com/ubuntu/
gb.archive.ubuntu.com/ubuntu/
security.ubuntu.com/ubuntu/
www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu/
ubuntu-archive.datahop.it/ubuntu/
so you control which of the above mirrors you use.
But in this case I don't think it will help as the update will be
coming from security.ubuntu.com and also because I think it is a
problem with the apt-cacher.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
So, a shutdown -h in terminal and then a power-up in
Zen console. Check!
Yep. You may want to log in to the xen shell console first so that
a) you know you can get in before you shut anything down, and b) you
can watch it shut down.
Get:13 http://apt-cacher.lon.bitfolk.com
hardy-updates/universe
linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
45% [13 linux-image-2.6.24-24-xen 8967518/18.8MB 47%]
----
Both of them are stuck around 45% download...
The apt-cacher will proxy a connection to the real Ubuntu mirrors if
it doesn't have the file locally, so it could be that the mirrors
are overloaded. Is it still happening?
As of a few seconds ago, yes. Still happening. mirror
hostname)?
Such as to http://gb.archive.ubuntu.com/ instead of
http://apt-cacher.lon.bitfolk.com ?
I can yes. I am, however, a bit reluctant to mess with live servers. If
it's what it takes to get things going, then naturally I'm up for it. 
1:28 p.m.
On Wed, 19 Aug 2009 12:15:44 +0000, Andy Smith <andy(a)bitfolk.com> wrote:
Does that apply for domUs virtualised under HVM too? I thought a reboot on
an HVM domU went all the way back to the BIOS.
Tony
> Why is this? I thought that, at least on Ubuntu a
'shutdown -r' picks up
the latest
kernel?!
On a normal machine with grub, a reboot gets you to the point where
the BIOS runs grub and grub gets kernel, initrd, etc.
On a Xen domU with pygrub, on domain creation pygrub runs in dom0
(the host server) to read your filesystem, extract your grub config
file, parse it to find the kernel, initrd etc., extract *those* to
a temporary directory and then create a domU with those files.
But on a reboot, Xen never actually destroys the virtual machine, it
just starts it again. That means it will have the same kernel
(pygrub is never run), same amount of RAM, most probably the same
size disk devices as well (I have never tested that bit).
1:36 p.m.
Hi Tony,
On Wed, Aug 19, 2009 at 02:28:11PM +0100, Tony Whitmore wrote:
On Wed, 19 Aug 2009 12:15:44 +0000, Andy Smith <andy(a)bitfolk.com> wrote:
Ah, this I do not know as I've only ever used Xen in
paravirtualisation mode. It wouldn't surprise me if they behaved
differently.
All BitFolk VPSes are currently PV-mode Xen domUs.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
"Greatness sits upon my shoulders as the dog urinates upon the pavement -
with naturalness and ease and some offence to passers-by."
-- The League Against Tedium
But on a reboot, Xen never actually destroys the
virtual machine, it
just starts it again. That means it will have the same kernel
(pygrub is never run), same amount of RAM, most probably the same
size disk devices as well (I have never tested that bit).
Does that apply for domUs virtualised under HVM too? I thought a reboot on
an HVM domU went all the way back to the BIOS.
4:37 p.m.
Andy,
On 19 Aug 2009, at 14:21, Andy Smith wrote:
Righto - I didn't realise that it fetches the files "real time" for
the
first time. Quite natural now when mentioned.
Okay. Can you try first an "apt-get update" and try it again?
I think it *is* some problem with apt-cache because it seems to have
first downloaded that package at 0741Z today. I've nuked its cache
now; it should proxy it again when someone asks for it.
Yes, worked perfectly on both VPS' now. Thanks for your help! :)
I will reboot them as soon as I can find a suitable moment.
In general the apt-cache URLs look like:
http://apt-cacher.lon.bitfolk.com/ubuntu/gb.archive.ubuntu.com/ubuntu/
The part after the first "ubuntu/" is the source mirror and path
that apt-cache will use if it doesn't have the file. Allowed hosts
for the Ubuntu apt-cacher are:
archive.ubuntu.com/ubuntu/
gb.archive.ubuntu.com/ubuntu/
security.ubuntu.com/ubuntu/
www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu/
ubuntu-archive.datahop.it/ubuntu/
so you control which of the above mirrors you use.
Very interesting. I've heard of APT caches before, but I've never used
them. Let alone set one up. Thanks for the info. :)
On Wed, Aug 19, 2009 at 01:39:45PM +0100, Jocke Selin
wrote:
Good point! :)
So, a shutdown -h in terminal and then a power-up
in Zen console.
Check!
Yep. You may want to log in to the xen shell console first so that
a) you know you can get in before you shut anything down, and b) you
can watch it shut down. Get:13
http://apt-cacher.lon.bitfolk.com hardy-updates/universe
linux-
image-2.6.24-24-xen 2.6.24-24.59 [18.8MB]
45% [13 linux-image-2.6.24-24-xen 8967518/18.8MB 47%]
----
Both of them are stuck around 45% download...
The apt-cacher will proxy a connection to the real Ubuntu mirrors if
it doesn't have the file locally, so it could be that the mirrors
are overloaded. Is it still happening?
As of a few seconds ago, yes. Still happening. mirror hostname)?
Such as to http://gb.archive.ubuntu.com/ instead of
http://apt-cacher.lon.bitfolk.com ?
I can yes. I am, however, a bit reluctant to mess with live
servers. If
it's what it takes to get things going, then naturally I'm up for it. But in this case I don't think it will help as the
update will be
coming from security.ubuntu.com and also because I think it is a
problem with the apt-cacher.
Seems to have been!
Thanks!!
Cheers,
/Jocke
5367
days inactive
5371
days old
9 comments
4 participants
participants (4)
-
Andy Smith -
David Bell -
Jocke Selin -
Tony Whitmore