13 Dec
2010
13 Dec
'10
5:19 p.m.
For those running Exim <= 4.69 (the default Debian
MTA), you should be
aware there is an exploit for remote *root* code execution in the wild.
I don't know whether to be worried or not... dpkg-query -l exim
exim 3.36-18.2 An obsolete MTA (Mail Transport
Agent), replaced by exim4
This is a virtual package designed to transition people to exim4
from years ago. Try again with exim4. You want 4.69-9+lenny1, if
we're talking about Debian lenny. 
13 Dec
13 Dec
5:25 p.m.
On Mon, Dec 13, 2010 at 05:19:20PM +0000, Philip Veale wrote:
Is there anyway to confirm whether or not this exploit is still
exposed in the 3.36-18.2 package...someone on another list suggested
it was not...
Read my reply again. You're looking at the wrong package. The
"exim" package is a virtual package left over from etch. The actual
exim package in Debian is "exim4". Look for the version of that:
dpkg-query -l exim
exim 3.36-18.2 An obsolete MTA (Mail Transport
Agent), replaced by exim4
This is a virtual package designed to transition people to exim4
from years ago. Try again with exim4. You want 4.69-9+lenny1, if
we're talking about Debian lenny. You want 4.69-9+lenny1, if we're talking about
Debian lenny.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
5:33 p.m.
After I upgraded, I looked for details under /usr/share/doc/exim4/
but it looked like none of the various changelog files had been updated
to explain the exact changes in 4.69-9+lenny1 - or am I missing
something?
Maybe apt-listchanges would have been more helpful, but I had
already upgraded before I thought of installing it.
On 13 December 2010 17:25, Andy Smith <andy(a)bitfolk.com> wrote:
On Mon, Dec 13, 2010 at 05:19:20PM +0000, Philip Veale
wrote:
Is there anyway to confirm whether or not this exploit is still
exposed in the 3.36-18.2 package...someone on another list suggested
it was not...
Read my reply again. You're looking at the wrong package. The
"exim" package is a virtual package left over from etch. The actual
exim package in Debian is "exim4". Look for the version of that:
dpkg-query -l exim
exim 3.36-18.2 An obsolete MTA (Mail Transport
Agent), replaced by exim4
This is a virtual package designed to transition people to exim4
from years ago. Try again with exim4. You want 4.69-9+lenny1, if
we're talking about Debian lenny. You want 4.69-9+lenny1, if we're talking
about Debian lenny.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
5:37 p.m.
Hi Adam,
$ zcat /usr/share/doc/exim4/changelog.Debian.gz | head -7
exim4 (4.69-9+lenny1) stable-security; urgency=high
* Non-maintainer upload by the Security Team.
* Fix SMTP file descriptors being leaked to processes invoked with ${run...}
* Fix memory corruption issue in string_format(). CVE-2010-4344
* Fix potential memory pool corruption issue in internal_lsearch_find().
Cheers,
Andy
On Mon, Dec 13, 2010 at 05:33:21PM +0000, Adam Spiers wrote:
After I upgraded, I looked for details under
/usr/share/doc/exim4/
but it looked like none of the various changelog files had been updated
to explain the exact changes in 4.69-9+lenny1 - or am I missing
something?
Maybe apt-listchanges would have been more helpful, but I had
already upgraded before I thought of installing it.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
16 Dec
16 Dec
10:16 a.m.
Hi all,
Maybe stating the obvious but despite many years of Linux experience I
got bitten :-(
I upgraded exim to the patched version immediately after reading
Dominic's warning a few days ago, but I think I forgot to restart it
in order for the patch to take effect, and this morning I woke up to
an email warning me that exim's paniclog contained:
2010-12-16 02:30:31 string too large in smtp_notquit_exit()
2010-12-16 04:37:17 string too large in smtp_notquit_exit()
2010-12-16 07:39:30 string too large in smtp_notquit_exit()
which sounds very much like the exploit. ARGH.
I installed chkrootkit, rkhunter, and unhide. rkhunter found nothing
of apparent substance, but chkrootkit said:
Checking `lkm'... You have 1 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installed
and 'unhide proc' output:
Unhide 20080519
yjesus(a)security-projects.com
[*]Searching for Hidden processes through /proc scanning
Found HIDDEN PID: 28213
Command: -bash
This bash process which doesn't go away with a reboot. So I'm
guessing that these days the kids are using trojan kernel modules,
which is no surprise as they are far more effective than the
old-fashioned ones.
This is my first experience with exim and I have to say I'm pretty
disgusted with it. This would never have happened with postfix which
would have been my first choice has proper privilege separation - I
can't believe in this day and age we're still using MTAs which run
monolithically as root.
I was hoping to compare the contents of /boot with the backups, but I
see these are not backed up. I installed debsums and it revealed the
following, although I'm not yet sure if this indicates a LKM rootkit or
not:
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.dep
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.pcimap
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.seriomap
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.symbols
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.usbmap
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.ieee1394map
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.alias
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.isapnpmap
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.inputmap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.ieee1394map
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.alias
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.usbmap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.seriomap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.pcimap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.isapnpmap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.dep
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.symbols
[snip]
debsums: checksum mismatch procps file /bin/ps
debsums: checksum mismatch procps file /bin/kill
debsums: checksum mismatch procps file /usr/bin/top
debsums: checksum mismatch procps file /usr/bin/tload
debsums: checksum mismatch procps file /usr/bin/pmap
debsums: checksum mismatch procps file /usr/bin/pwdx
debsums: checksum mismatch procps file /usr/bin/watch
debsums: checksum mismatch procps file /usr/bin/vmstat
debsums: checksum mismatch procps file /usr/bin/skill
debsums: checksum mismatch procps file /usr/bin/uptime
debsums: checksum mismatch procps file /usr/bin/pgrep
debsums: checksum mismatch procps file /usr/bin/free
debsums: checksum mismatch procps file /usr/bin/slabtop
debsums: checksum mismatch procps file /sbin/sysctl
For now I have shut down networking and am only using the Xen console.
Adam
On 13 December 2010 17:37, Andy Smith <andy(a)bitfolk.com> wrote:
Hi Adam,
$ zcat /usr/share/doc/exim4/changelog.Debian.gz | head -7
exim4 (4.69-9+lenny1) stable-security; urgency=high
* Non-maintainer upload by the Security Team.
* Fix SMTP file descriptors being leaked to processes invoked with ${run...}
* Fix memory corruption issue in string_format(). CVE-2010-4344
* Fix potential memory pool corruption issue in internal_lsearch_find().
Cheers,
Andy
On Mon, Dec 13, 2010 at 05:33:21PM +0000, Adam Spiers wrote:
After I upgraded, I looked for details under
/usr/share/doc/exim4/
but it looked like none of the various changelog files had been updated
to explain the exact changes in 4.69-9+lenny1 - or am I missing
something?
Maybe apt-listchanges would have been more helpful, but I had
already upgraded before I thought of installing it.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREDAAYFAk0GWcEACgkQIJm2TL8VSQtvRgCgrdHw2gQz5b+0Ey8H2rk3/TaU
QyAAn3x2Zg/X9A5vedVhZ1jLawfypBkq
=PaSt
-----END PGP SIGNATURE-----
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
10:26 a.m.
Just to eliminate any further doubt of this being a rootkit:
On 16 December 2010 10:16, Adam Spiers <bitfolk(a)adamspiers.org> wrote:
and 'unhide proc' output:
Unhide 20080519
yjesus(a)security-projects.com
[*]Searching for Hidden processes through /proc scanning
Found HIDDEN PID: 28213
Command: -bash
This bash process which doesn't go away with a reboot.
lsof -p on the bash process reveals:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
dropbear 1938 root cwd DIR 202,0 4096 2 /
dropbear 1938 root rtd DIR 202,0 4096 2 /
dropbear 1938 root txt REG 202,0 589672 346434 /usr/include/sslv3/dropbear
dropbear 1938 root 3u IPv6 4292 TCP *:44965 (LISTEN)
Also:
# dpkg -S /usr/include/sslv3/dropbear
dpkg: /usr/include/sslv3/dropbear not found.
# l /usr/include/sslv3/dropbear
-rwxr-xr-x 1 root root 576K 2010-12-16 02:24 /usr/include/sslv3/dropbear*
so the exploit starts up a trojaned dropbear sshd service on a high port
and masquerades it as a bash process. I would love to know how it gets
started up but I have to pack for Asia now :-(
11:56 a.m.
Thanks Adam, for this nice summary of rootkit security measures!
% apt-get install chkroootkit
% apt-get install rkhunter # installs 'unhide' as a byproduct
% apt-get install debsums
For the record, and because man pages rarely have examples...
% chkrootkit
% rkhunter -c
% more /var/log/rkhunter.log
% unhide proc
% unhide sys
% unhide brute
% debsums -a | grep mismatch
I ran 'unhide sys' five times with odd results: reports of two, one, two, zero
and one 'HIDDEN PROCESSES found', which leads me to wonder whether
'unhide'
reports mismatches but does not account well for the unix scheduler and the
finite nature of time division. (A process might be declared by unhide as
'hidden' when, in between of two lines of 'unhide' code, the
scheduler terminates a process.) The 'unhide' man page is written at too high a
level for this reader. What does one do next in this case??
Cheers,
Max
________________________________
From: Adam Spiers <bitfolk(a)adamspiers.org>
To: Andy Smith <andy(a)bitfolk.com>
Cc: users(a)lists.bitfolk.com
Sent: Thu, December 16, 2010 10:16:10 AM
Subject: Re: [bitfolk] Exim remote root exploit
Hi all,
Maybe stating the obvious but despite many years of Linux experience I
got bitten :-(
I upgraded exim to the patched version immediately after reading
Dominic's warning a few days ago, but I think I forgot to restart it
in order for the patch to take effect, and this morning I woke up to
an email warning me that exim's paniclog contained:
2010-12-16 02:30:31 string too large in smtp_notquit_exit()
2010-12-16 04:37:17 string too large in smtp_notquit_exit()
2010-12-16 07:39:30 string too large in smtp_notquit_exit()
which sounds very much like the exploit. ARGH.
I installed chkrootkit, rkhunter, and unhide. rkhunter found nothing
of apparent substance, but chkrootkit said:
Checking `lkm'... You have 1 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installed
and 'unhide proc' output:
Unhide 20080519
yjesus(a)security-projects.com
[*]Searching for Hidden processes through /proc scanning
Found HIDDEN PID: 28213
Command: -bash
This bash process which doesn't go away with a reboot. So I'm
guessing that these days the kids are using trojan kernel modules,
which is no surprise as they are far more effective than the
old-fashioned ones.
This is my first experience with exim and I have to say I'm pretty
disgusted with it. This would never have happened with postfix which
would have been my first choice has proper privilege separation - I
can't believe in this day and age we're still using MTAs which run
monolithically as root.
I was hoping to compare the contents of /boot with the backups, but I
see these are not backed up. I installed debsums and it revealed the
following, although I'm not yet sure if this indicates a LKM rootkit or
not:
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.dep
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.pcimap
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.seriomap
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.symbols
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.usbmap
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.ieee1394map
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.alias
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.isapnpmap
debsums: checksum mismatch linux-modules-2.6.26-1-xen-686 file
/lib/modules/2.6.26-1-xen-686/modules.inputmap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.ieee1394map
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.alias
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.usbmap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.seriomap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.pcimap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.isapnpmap
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.dep
debsums: checksum mismatch linux-modules-2.6.26-2-xen-686 file
/lib/modules/2.6.26-2-xen-686/modules.symbols
[snip]
debsums: checksum mismatch procps file /bin/ps
debsums: checksum mismatch procps file /bin/kill
debsums: checksum mismatch procps file /usr/bin/top
debsums: checksum mismatch procps file /usr/bin/tload
debsums: checksum mismatch procps file /usr/bin/pmap
debsums: checksum mismatch procps file /usr/bin/pwdx
debsums: checksum mismatch procps file /usr/bin/watch
debsums: checksum mismatch procps file /usr/bin/vmstat
debsums: checksum mismatch procps file /usr/bin/skill
debsums: checksum mismatch procps file /usr/bin/uptime
debsums: checksum mismatch procps file /usr/bin/pgrep
debsums: checksum mismatch procps file /usr/bin/free
debsums: checksum mismatch procps file /usr/bin/slabtop
debsums: checksum mismatch procps file /sbin/sysctl
For now I have shut down networking and am only using the Xen console.
Adam
On 13 December 2010 17:37, Andy Smith <andy(a)bitfolk.com> wrote:
Hi Adam,
$ zcat /usr/share/doc/exim4/changelog.Debian.gz | head -7
exim4 (4.69-9+lenny1) stable-security; urgency=high
* Non-maintainer upload by the Security Team.
* Fix SMTP file descriptors being leaked to processes invoked with ${run...}
* Fix memory corruption issue in string_format(). CVE-2010-4344
* Fix potential memory pool corruption issue in internal_lsearch_find().
Cheers,
Andy
On Mon, Dec 13, 2010 at 05:33:21PM +0000, Adam Spiers wrote:
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
After I upgraded, I looked for details under
/usr/share/doc/exim4/
but it looked like none of the various changelog files had been updated
to explain the exact changes in 4.69-9+lenny1 - or am I missing
something?
Maybe apt-listchanges would have been more helpful, but I had
already upgraded before I thought of installing it.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREDAAYFAk0GWcEACgkQIJm2TL8VSQtvRgCgrdHw2gQz5b+0Ey8H2rk3/TaU
QyAAn3x2Zg/X9A5vedVhZ1jLawfypBkq
=PaSt
-----END PGP SIGNATURE-----
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
11:58 a.m.
On 16 December 2010 11:56, Max B <txtmax(a)yahoo.ca> wrote:
I ran 'unhide sys' five times with odd
results: reports of two, one, two,
zero and one 'HIDDEN PROCESSES found', which leads me to wonder whether
'unhide' reports mismatches but does not account well for the unix scheduler
and the finite nature of time division. (A process might be declared by
unhide as 'hidden' when, in between of two lines of 'unhide' code, the
scheduler terminates a process.) The 'unhide' man page is written at too
high a level for this reader. What does one do next in this case??
Try running lsof -p on the hidden process ids.
12:13 p.m.
New subject: 'unhide sys' command, was Re: Exim remote root exploit
Adam,
thanks more! I was only dimly aware of the 'lsof' command.
unfortunately:
% unhide sys
Unhide 20080519
does not report the pid numbers, nor does the man page indicate a command line
'verbose' switch, nor does the unhide command generate a telltale /var/log
summary:
% ls /var/log/*hi*.
ls: No such file or directory.
and the 'lsof -p' command requires a pid argument.
I am unfortunately in no position to write code to amend this state of affairs.
Cheers,
Max
________________________________
From: Adam Spiers <bitfolk(a)adamspiers.org>
To: Max B <txtmax(a)yahoo.ca>
Cc: users(a)lists.bitfolk.com
Sent: Thu, December 16, 2010 11:58:34 AM
Subject: Re: [bitfolk] Exim remote root exploit
On 16 December 2010 11:56, Max B <txtmax(a)yahoo.ca> wrote:
I ran 'unhide sys' five times with odd
results: reports of two, one, two,
zero and one 'HIDDEN PROCESSES found', which leads me to wonder whether
'unhide' reports mismatches but does not account well for the unix scheduler
and the finite nature of time division. (A process might be declared by
unhide as 'hidden' when, in between of two lines of 'unhide' code, the
scheduler terminates a process.) The 'unhide' man page is written at too
high a level for this reader. What does one do next in this case??
Try running lsof -p on the hidden process ids.
12:18 p.m.
New subject: 'unhide sys' command, was Re: Exim remote root exploit
On 16 December 2010 12:13, Max B <txtmax(a)yahoo.ca> wrote:
Adam,
thanks more! I was only dimly aware of the 'lsof' command.
No problem. I did mention it in my previous mail though ;-)
unfortunately:
% unhide sys
Unhide 20080519
does not report the pid numbers, nor does the man page indicate a command
line 'verbose' switch, nor does the unhide command generate a telltale
/var/log summary:
What about 'unhide proc' or 'unhide brute' or just 'unhide' ?
12:28 p.m.
New subject: 'unhide sys' command, was Re: Exim remote root exploit
Adam, Alex,
% unhide proc
% unhide brute
continue to report no problems.
% unhide
is just a call to 'usage' and exit.
I am inclined to the advice of Alex Hudson, who writes that unhide is bound to
be racey on virtual machines.
Thanks for your help, both.
Cheers,
Max
________________________________
From: Adam Spiers <bitfolk(a)adamspiers.org>
To: Max B <txtmax(a)yahoo.ca>
Cc: users(a)lists.bitfolk.com
Sent: Thu, December 16, 2010 12:18:39 PM
Subject: Re: [bitfolk] 'unhide sys' command, was Re: Exim remote root exploit
On 16 December 2010 12:13, Max B <txtmax(a)yahoo.ca> wrote:
Adam,
thanks more! I was only dimly aware of the 'lsof' command.
No problem. I did mention it in my previous mail though ;-)
unfortunately:
% unhide sys
Unhide 20080519
does not report the pid numbers, nor does the man page indicate a command
line 'verbose' switch, nor does the unhide command generate a telltale
/var/log summary:
What about 'unhide proc' or 'unhide brute' or just 'unhide' ?
12:23 p.m.
On Thu, 2010-12-16 at 03:56 -0800, Max B wrote:
I ran 'unhide sys' five times with odd
results: reports of two, one,
two, zero and one 'HIDDEN PROCESSES found', which leads me to wonder
whether 'unhide' reports mismatches but does not account well for the
unix scheduler and the finite nature of time division. (A process
might be declared by unhide as 'hidden' when, in between of two lines
of 'unhide' code, the scheduler terminates a process.)
I wouldn't worry about it, particularly on a VM that kind of check is
going to be so racey you'll get false positives.
Unless one of the other checks has turned something up, I don't think
you have an issue.
Cheers
Alex.
--
This message was scanned by Better Hosted and is believed to be clean.
http://www.betterhosted.com
3:30 p.m.
Andy, I don't see that:
# dpkg -l exim4
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name Version Description
+++-================-================-================================================
ii exim4 4.69-9+lenny1 metapackage to ease Exim MTA
(v4) installation
# zcat /usr/share/doc/exim4/changelog.Debian.gz | head -7
exim4 (4.69-9) unstable; urgency=medium
* [update-exim4.conf]: Use POSIX character classes [:alnum:] or explicit
listing ("ABCDEF..") instead of a-z, since the latter does not work as
expected in some locales. Closes: #500691
-- Andreas Metzler <ametzler(a)debian.org> Tue, 30 Sep 2008 20:12:27 +0200
What am I missing?
On 13 December 2010 17:37, Andy Smith <andy(a)bitfolk.com> wrote:
Hi Adam,
$ zcat /usr/share/doc/exim4/changelog.Debian.gz | head -7
exim4 (4.69-9+lenny1) stable-security; urgency=high
* Non-maintainer upload by the Security Team.
* Fix SMTP file descriptors being leaked to processes invoked with ${run...}
* Fix memory corruption issue in string_format(). CVE-2010-4344
* Fix potential memory pool corruption issue in internal_lsearch_find().
Cheers,
Andy
On Mon, Dec 13, 2010 at 05:33:21PM +0000, Adam Spiers wrote:
> After I upgraded, I looked for details under /usr/share/doc/exim4/
> but it looked like none of the various changelog files had been updated
> to explain the exact changes in 4.69-9+lenny1 - or am I missing
> something?
>
> Maybe apt-listchanges would have been more helpful, but I had
> already upgraded before I thought of installing it.
13 Dec
13 Dec
5:36 p.m.
Is there
anyway to confirm whether or not this exploit is still
exposed in the 3.36-18.2 package...someone on another list suggested
it was not...
Read my reply again. You're looking at the wrong package. The
"exim" package is a virtual package left over from etch. The actual
exim package in Debian is "exim4". Look for the version of that:
> You want 4.69-9+lenny1, if we're talking about Debian lenny.
5:47 p.m.
Hi Philip,
On Mon, Dec 13, 2010 at 05:36:48PM +0000, Philip Veale wrote:
No, I really am running 3.36 and not 4.x
I'm not even sure what version the distro is now, the apt sources are
a horrible mess. It's _old_ anyway :(
Possibly you are running debian sarge then, in which case I'm amazed
you're still in control of the server. :/
I don't think there's been a *remote* root exploit in anything
common since then but plenty of local ones..
I'm not sure of the steps to reproduce the exploit. You may well be
right that your exim is too old to be affected but I wouldn't rely
on it. Also there's bound to be something else, so I'd recommend
taking advantage of:
https://tools.bitfolk.com/wiki/Migrating_to_a_new_VPS
as a matter of urgency.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
4878
days inactive
4881
days old
14 comments
5 participants
participants (5)
-
Adam Spiers -
Alex Hudson -
Andy Smith -
Max B -
Philip Veale