apt-get doesn't find
> > anything to update. Thanks in advance.
>
> Security support for oldstable has ended at the end of the month, but
> there is squeeze-lts available.
>
> See
>
> https://lists.debian.org/debian-security-announce/2014/msg00119.html
>
> Updat
ble.
See
https://lists.debian.org/debian-security-announce/2014/msg00119.html
Updates for squeeze-lts for chkrootkit are also beeing prepared,
AFAIK.
Hope that helps,
Regards,
Salvatore
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscri
p://www.debian.org/security/faq
> - -----
>
> Package: chkrootkit
> CVE ID : CVE-2014-0476
>
> Thomas Stangner discovered a vulnerability in chkrootkit, a rootkit
> detector, which may allow local attackers to gain root access when /tmp
> is mounted wit
On Mon, Aug 14, 2006 at 11:09:54AM +0300, Henri Salo wrote:
> Lothar Ketterer wrote:
> >and chkrootkit (version 0.46a) gives me
> >
> >eth0: PF_PACKET(/sbin/dhclient, /usr/sbin/arpwatch)
> >
> >lo is not mentioned.
I just checked with chkrootkit version 44-2 (s
eth0 inet dhcp
and chkrootkit (version 0.46a) gives me
eth0: PF_PACKET(/sbin/dhclient, /usr/sbin/arpwatch)
lo is not mentioned.
Regards,
Lothar
With ifup in unstable machine:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
--
Henri Salo
[EMAIL PROTECTED]
0407705733
--
To
Hi,
> It remains strange because normally, lo is a non-broadcast interface.
Maybe it would help to know how Henri has his network configured. Mine
is configured with ifupdown, /etc/network/interfaces looks like this:
auto lo eth0
iface lo inet loopback
iface eth0 inet dhcp
and chkroot
t's just because of a different dhcp-client? Or the higher version of
chkrootkit?
Greetings,
Christian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Fri, Aug 11, 2006 at 11:40:24AM +0200, Izak Burger wrote:
> On 8/11/06, Christian Schuerer <[EMAIL PROTECTED]> wrote:
> >Isn't it strange that there is an DHCP client running on lo? I don't get
> >the
> >point of doing that.
> The pid is the same for all three (29184), so it is obviously a
> p
On 8/11/06, Christian Schuerer <[EMAIL PROTECTED]> wrote:
Isn't it strange that there is an DHCP client running on lo? I don't get the
point of doing that.
The pid is the same for all three (29184), so it is obviously a
process that binds to 0.0.0.0, and as a result, ends up listening on
lo as
On Thursday 10 August 2006 23:23, Sven Hartge wrote:
> Um 22:48 Uhr am 10.08.06 schrieb Henri Salo:
> > I am running Debian stable (kernel 2.6.8-2) chkrootkit version 0.44 with
> > command chkrootkit and it gives me:
> >
> > Checking `sniffer'... lo: PACKET SNIFFER
Um 22:48 Uhr am 10.08.06 schrieb Henri Salo:
> I am running Debian stable (kernel 2.6.8-2) chkrootkit version 0.44 with
> command chkrootkit and it gives me:
>
> Checking `sniffer'... lo: PACKET SNIFFER(/sbin/dhclient[29148])
> eth0: PACKET SNIFFER(/sbin/dhclient[29148],
I am running Debian stable (kernel 2.6.8-2) chkrootkit version 0.44 with
command chkrootkit and it gives me:
Checking `sniffer'... lo: PACKET SNIFFER(/sbin/dhclient[29148])
eth0: PACKET SNIFFER(/sbin/dhclient[29148], /sbin/dhclient[29307])
eth1: PACKET SNIFFER(/sbin/dhclient[29148])
is
>
> (I hope you don't mind if I publish our correspondence in Linux Gazette,
> http://linuxgazette.net/ .)
>
No problem at all.
Kevin Bailey
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hi ya thomas
On Wed, 30 Nov 2005, Thomas Hochstein wrote:
> Alvin Oga schrieb:
>
> > - fresh installs means you have to configure everything
> > again from nothing .. maybe 1hr ..maybe 1 day .. maybe 1 week
>
> No, you don't; you can just review the configuration file(s) manually
> or
Quoting Thomas Hochstein ([EMAIL PROTECTED]):
> That is not a good idea in a typical hosting environment; if you push
> your backup and the machine to be backupped is compromised, the
> attacker has access to your backups too because the automatic backup
> process has to have the necessary credent
Alvin Oga schrieb:
> - fresh installs means you have to configure everything
> again from nothing .. maybe 1hr ..maybe 1 day .. maybe 1 week
No, you don't; you can just review the configuration file(s) manually
or check them against a known good backup.
> always push backups, since r
ays, weeks, months before you find
that you've been had ..
> regularly run chkrootkit and get the server to email the results to you.
i wouldn't place too much confidence on binaries running on suspect
hacked boxes, even if its for sanity checking, and first pass
notificati
Rick Moen wrote:
>
> Unsafe data passed to eval(). Sheesh!
And awstats is so large, that it would require a lot of effort to do a
proper audit of it. Are their any automated tools for auditing perl code?
Or I wonder what would happen if you just switced on taint mode?
>
>>I would agree
Quoting Geoff Crompton ([EMAIL PROTECTED]):
> The most recent vulnerability that I was aware of in Awstats can still
> work even in static mode. http://www.securityfocus.com/bid/14525. The
> referrer in the log file is not sanity checked.
Hmm. I note: "It should be noted this vulnerability is o
> So, here's my favourite example of the "bad implementation" problem:
> AWstats. It's had a long history of:
>
> o Someone finds yet another way its stats-generating CGI can be subverted by
>sending it aberrant URL information from the public.
> o The upstream maintainer issues an update.
On Tuesday 29 November 2005 14.04, kevin bailey wrote:
> if backing up to another server get that server to pull backups out. on
> my new machines i was pushing out the backups from the primary server -
> this would mean a cracker would then have an easy way in to the backup
> machine because i wa
esh software from trusted media, avoiding direct reuse of any
of your existing configuration files or user dotfiles.
http://www.cert.org/tech_tips/win-UNIX-system_compromise.html
> main points learnt.
>
> make sure you have snapshot backups going back months.
>
> regularly run
ain points learnt.
make sure you have snapshot backups going back months.
regularly run chkrootkit and get the server to email the results to you.
if backing up to another server get that server to pull backups out. on my
new machines i was pushing out the backups from the primary server - this
On Tue, Nov 29, 2005 at 04:34:11AM +, kevin bailey wrote:
> hi,
>
> the following output looks like i've been rooted.
Yes, it doesn't look like a false positive:
> Checking `ls'... INFECTED
> Checking `netstat'... INFECTED
> Checking `ps'... INFECTED
> Checking `top'... INFECTED
Nasty.
> S
and..
:/usr/local/sbin# /usr/lib/chkrootkit/chkproc -v
PID 4: not in ps output
PID 1769: not in ps output
PID 15688: not in ps output
PID 15690: not in ps output
PID 17760: not in ps output
PID 17762: not in ps output
PID 21583: not in ps output
PID 21585: not in ps output
PID 21919: not in
.
thanks,
kev
:/usr/local/sbin# chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'
Hi Rick,
> Why don't you make a copy of one or more of those binaries, then
> re-retrieve and install the Woody package of the same release, and
> compare md5sums of the resulting binaries? (Note that you should make
> very sure it's the same release, or you'll get a different md5sum for
> entire
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> Rootkit Hunter found some bad or unknown hashes. This can be happen due
> replaced binaries or updated packages (which give other hashes). Be sure
> your hashes are fully updated (rkhunter --update). If you're in doubt
> about these hashes, contact
Incoming from [EMAIL PROTECTED]:
>
> chkrootkit found nothing but rkhunter found quite a lot:
>
> /bin/login /bin/su /usr/bin/locate /usr/sbin/useradd /usr/sbin/usermod
> /usr/sbin/vip
>
> All these binaries have been alerted within rkhunter.
>
> I got a messag
Hello,
it now it was a couple of days ago but I've to concern
another time to in this case a compromised woody system.
chkrootkit found nothing but rkhunter found quite a lot:
/bin/login /bin/su /usr/bin/locate /usr/sbin/useradd /usr/sbin/usermod
/usr/sbin/vip
All these binaries have
* Quoting Bas ([EMAIL PROTECTED]):
> If you do not run Portsentry you have a problem..
I disagree.
There could be another process listening at that.
- Rolf
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I presume you run Portsentry on the same machine if you
do than the blindshell INFECTED is nothing to worry about
ITs normal behavior if you run Portsentry and chkrootkit on the same
machine.
If you do not run Portsentry you have a problem..
Bas
--
To UNSUBSCRIBE, email to [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 24 Feb 2004 14:32:26 +0100,
Greg <[EMAIL PROTECTED]> wrote:
> I am running Debian on a Dec Alpha PC164.
>
> I decided to run chkrootkit and was surprised by the following line.
>
> Checking `bindshell'... INFECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 24 Feb 2004 14:32:26 +0100,
Greg <[EMAIL PROTECTED]> wrote:
> I am running Debian on a Dec Alpha PC164.
>
> I decided to run chkrootkit and was surprised by the following line.
>
> Checking `bindshell'... INFECTED
On Tue, Feb 24, 2004 at 10:37:44AM -0500, Noah Meyerhans wrote:
> On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote:
> >
> > Looks like there are a lot of false positives on it.
> >
>
> It looks like there are a lot of false positives with chkrootkit in
> ge
Alohá!
Noah Meyerhans wrote:
> On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote:
>
>> Looks like there are a lot of false positives on it.
>>
>
>
> It looks like there are a lot of false positives with chkrootkit in
> general. Seriously, has anybody here
On Tue, Feb 24, 2004 at 10:37:44AM -0500, Noah Meyerhans wrote:
> On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote:
> >
> > Looks like there are a lot of false positives on it.
> >
>
> It looks like there are a lot of false positives with chkrootkit in
> ge
On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote:
>
> Looks like there are a lot of false positives on it.
>
It looks like there are a lot of false positives with chkrootkit in
general. Seriously, has anybody here ever had chkrootkit detect an
actual rootkit? Questions about i
Alohá!
Noah Meyerhans wrote:
> On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote:
>
>> Looks like there are a lot of false positives on it.
>>
>
>
> It looks like there are a lot of false positives with chkrootkit in
> general. Seriously, has anybody here
On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote:
>
> Looks like there are a lot of false positives on it.
>
It looks like there are a lot of false positives with chkrootkit in
general. Seriously, has anybody here ever had chkrootkit detect an
actual rootkit? Questions about i
31337 - are your runing portsentry on that machine ?
Quote from the www.chkrootkit.org site:
I'm running PortSentry/klaxon. What's wrong with the bindshell test?
If you're running PortSentry/klaxon or another program that binds itself
to unused ports probably chkrootkit will g
May be you have installed "fakebo"?
Billy
S
At 08:53 AM 2/24/2004, Greg wrote:
I am running Debian on a Dec Alpha PC164.
I decided to run chkrootkit and was surprised by the following line.
Checking `bindshell'... INFECTED (PORTS: 1524 31337)
I am not sure how no interpret this. I have checked logs, as well as binary
checks an
On Tuesday 24 February 2004 07:53, Greg wrote:
> I am running Debian on a Dec Alpha PC164.
>
> I decided to run chkrootkit and was surprised by the following line.
>
> Checking `bindshell'... INFECTED (PORTS: 1524 31337)
Try a nmap port scan from the outside to your ip add
I am running Debian on a Dec Alpha PC164.
I decided to run chkrootkit and was surprised by the following line.
Checking `bindshell'... INFECTED (PORTS: 1524 31337)
I am not sure how no interpret this. I have checked logs, as well as binary
checks and everything "seems" fine. C
31337 - are your runing portsentry on that machine ?
Quote from the www.chkrootkit.org site:
I'm running PortSentry/klaxon. What's wrong with the bindshell test?
If you're running PortSentry/klaxon or another program that binds itself
to unused ports probably chkrootkit will g
May be you have installed "fakebo"?
Billy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
t 08:53 AM 2/24/2004, Greg wrote:
I am running Debian on a Dec Alpha PC164.
I decided to run chkrootkit and was surprised by the following line.
Checking `bindshell'... INFECTED (PORTS: 1524 31337)
I am not sure how no interpret this. I have checked logs, as well as binary
checks and ever
On Tuesday 24 February 2004 07:53, Greg wrote:
> I am running Debian on a Dec Alpha PC164.
>
> I decided to run chkrootkit and was surprised by the following line.
>
> Checking `bindshell'... INFECTED (PORTS: 1524 31337)
Try a nmap port scan from the outside to your ip add
I am running Debian on a Dec Alpha PC164.
I decided to run chkrootkit and was surprised by the following line.
Checking `bindshell'... INFECTED (PORTS: 1524 31337)
I am not sure how no interpret this. I have checked logs, as well as binary
checks and everything "seems" fine. C
Incoming from Jordan Lederman:
>
> While doing some normal system maintenance on a box of mine that primarily
> runs snort as an ids, I ran chkrootkit which ran cleanly, reporting nothing
> out of the ordinary. Normally this is a good thing, but then I got to
> thinking that
Incoming from Jordan Lederman:
>
> While doing some normal system maintenance on a box of mine that primarily
> runs snort as an ids, I ran chkrootkit which ran cleanly, reporting nothing
> out of the ordinary. Normally this is a good thing, but then I got to
> thinking that
While doing some normal system maintenance on a box of mine that primarily
runs snort as an ids, I ran chkrootkit which ran cleanly, reporting nothing
out of the ordinary. Normally this is a good thing, but then I got to
thinking that if I am running snort, than I am in promiscuous mode and
While doing some normal system maintenance on a box of mine that primarily
runs snort as an ids, I ran chkrootkit which ran cleanly, reporting nothing
out of the ordinary. Normally this is a good thing, but then I got to
thinking that if I am running snort, than I am in promiscuous mode and
[On 04 Dec, @07:24, Paul wrote in "Re: chkrootkit and linux 2.6 ..."]
>I see this same behavior with 2.6.0-test8. Chkrookit comes up with 42
>processes possibly caused by LKM rootkit. I would have 69 processes
>running with 42 of them owned by root. When I boot
I see this same behavior with 2.6.0-test8. Chkrookit comes up with 42 processes possibly caused by LKM rootkit. I would have 69 processes running with 42 of them owned by root. When I boot back to 2.4.23, it comes up with the 4 mentioned in the bug. I'm no Linux master by any means, but I'm
[On 04 Dec, @07:24, Paul wrote in "Re: chkrootkit and linux 2.6 ..."]
>I see this same behavior with 2.6.0-test8. Chkrookit comes up with 42
>processes possibly caused by LKM rootkit. I would have 69 processes
>running with 42 of them owned by root. When I boot
I see this same behavior with 2.6.0-test8. Chkrookit comes up with 42 processes possibly caused by LKM rootkit. I would have 69 processes running with 42 of them owned by root. When I boot back to 2.4.23, it comes up with the 4 mentioned in the bug. I'm no Linux master by any means, but I'm
[On 02 Dec, @20:56, David wrote in "Re: chkrootkit and linux 2.6 ..."]
>
> Right now chkrootkit gets lots of false positives regarding LKMs. There
> was a pretty thorough discussion just a couple days ago so look through
> the archive for the details:
> http://lists.d
On Wed, Dec 03, 2003 at 10:05:10AM +0100, Miek Gieben wrote:
> I more and more start to think this is a bug in chkrootkit - on
> busier systems more processes are hidded than on quiet systems.
Sounds to me as a race condition: number of processes changes between
the two checks.
Inde
[On 03 Dec, @07:28, Hideki wrote in "Re: chkrootkit and linux 2.6 ..."]
> Hi,
>
> Miek, if you are using kernel 2.6-test6 or newer, maybe not
> worry about brk() bug. this kernel vulnerability effects under
> 2.4.22 and 2.6-test5.
I know, thanks. I'm running
[On 02 Dec, @20:56, David wrote in "Re: chkrootkit and linux 2.6 ..."]
>
> Right now chkrootkit gets lots of false positives regarding LKMs. There
> was a pretty thorough discussion just a couple days ago so look through
> the archive for the details:
> http://lists.d
On Wed, Dec 03, 2003 at 10:05:10AM +0100, Miek Gieben wrote:
> I more and more start to think this is a bug in chkrootkit - on
> busier systems more processes are hidded than on quiet systems.
Sounds to me as a race condition: number of processes changes between
the two checks.
Inde
[On 03 Dec, @07:28, Hideki wrote in "Re: chkrootkit and linux 2.6 ..."]
> Hi,
>
> Miek, if you are using kernel 2.6-test6 or newer, maybe not
> worry about brk() bug. this kernel vulnerability effects under
> 2.4.22 and 2.6-test5.
I know, thanks. I'm running
Hi,
Miek, if you are using kernel 2.6-test6 or newer, maybe not
worry about brk() bug. this kernel vulnerability effects under
2.4.22 and 2.6-test5.
in DSA-403,
>This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and
>2.6.0-test6 kernel tree. For Debian it has been fixed in v
Hi,
Miek, if you are using kernel 2.6-test6 or newer, maybe not
worry about brk() bug. this kernel vulnerability effects under
2.4.22 and 2.6-test5.
in DSA-403,
>This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and
>2.6.0-test6 kernel tree. For Debian it has been fixed in v
Right now chkrootkit gets lots of false positives regarding LKMs. There
was a pretty thorough discussion just a couple days ago so look through
the archive for the details:
http://lists.debian.org/debian-security/
So, its _probably_ a false alarm, but
--
David Ehle
Computing Systems
Right now chkrootkit gets lots of false positives regarding LKMs. There
was a pretty thorough discussion just a couple days ago so look through
the archive for the details:
http://lists.debian.org/debian-security/
So, its _probably_ a false alarm, but
--
David Ehle
Computing Systems
Hello,
When reading again about the (Debian) breakin, it said you should run chkrootkit
to see if you have a rootkit installed. Well I did. But now it is complaining
about a LKM rootkit. But i'm running a 2.6 kernel, is this still valid then?
I've checked the md5sums of some commands
Hello,
When reading again about the (Debian) breakin, it said you should run chkrootkit
to see if you have a rootkit installed. Well I did. But now it is complaining
about a LKM rootkit. But i'm running a 2.6 kernel, is this still valid then?
I've checked the md5sums of some commands
Spamassassin combined do create false
> positives.
This is a known bug in chkrootkit - there is a race condition in the
code such that on a relatively busy system (or a sluggish one), there is a
difference in the ouput because of time lag - first it checks ps, then
it checks /proc, and if t
Spamassassin combined do create false
> positives.
This is a known bug in chkrootkit - there is a race condition in the
code such that on a relatively busy system (or a sluggish one), there is a
difference in the ouput because of time lag - first it checks ps, then
it checks /proc, and if t
I'm not quite sure if i'm right .. but isn't there a kernel bug
displaying some processes with PID 0 in ps or top.
maybe lkm is using this..
just a thought
greets Werner
> > > Checking `lkm'... You have 4 process hidden for ps command
> > > Warning: Possible LKM Trojan installed
I
signat
I'm not quite sure if i'm right .. but isn't there a kernel bug
displaying some processes with PID 0 in ps or top.
maybe lkm is using this..
just a thought
greets Werner
> > > Checking `lkm'... You have 4 process hidden for ps command
> > > Warning: Possible LKM Trojan installed
I
signat
In article <[EMAIL PROTECTED]> you wrote:
> Am I right to assume that this is not the lkm kit, but rather some
> weiredness in PID assignment?
it is a ps/kernel bug, try top.
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Am Di, den 25.11.2003 schrieb Johannes Graumann um 21:18:
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possible LKM Trojan installed
The same here (debian_sid):
In article <[EMAIL PROTECTED]> you wrote:
> Am I right to assume that this is not the lkm kit, but rather some
> weiredness in PID assignment?
it is a ps/kernel bug, try top.
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
--
To UNSUBSCRIBE,
Am Di, den 25.11.2003 schrieb Johannes Graumann um 21:18:
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possible LKM Trojan installed
The same here (debian_sid):
/2003 à 01:17, Michael Bordignon a écrit :
> > I was just running 'chkrootkit' and came across this warning:
> >
> > > Checking `lkm'... You have 4 process hidden for ps command
> > > Warning: Possible LKM Trojan installed
>
> I have the same pro
/2003 à 01:17, Michael Bordignon a écrit :
> > I was just running 'chkrootkit' and came across this warning:
> >
> > > Checking `lkm'... You have 4 process hidden for ps command
> > > Warning: Possible LKM Trojan installed
>
> I have the same pro
Le mer 26/11/2003 à 01:17, Michael Bordignon a écrit :
> > I was just running 'chkrootkit' and came across this warning:
> >
> > > Checking `lkm'... You have 4 process hidden for ps command
> > > Warning: Possible LKM Trojan installed
>
>
Le mer 26/11/2003 à 01:17, Michael Bordignon a écrit :
> > I was just running 'chkrootkit' and came across this warning:
> >
> > > Checking `lkm'... You have 4 process hidden for ps command
> > > Warning: Possible LKM Trojan installed
>
>
On Tue, Nov 25, 2003 at 06:42:21PM -0600, Adam Heath scribbled:
[snip]
> > are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated)
> > in existence that show a PID of 0.
> > Am I right to assume that this is not the lkm kit, but rather some
> > weiredness in PID assignment?
> >
> > T
On Tue, Nov 25, 2003 at 06:42:21PM -0600, Adam Heath scribbled:
[snip]
> > are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated)
> > in existence that show a PID of 0.
> > Am I right to assume that this is not the lkm kit, but rather some
> > weiredness in PID assignment?
> >
> > T
Thanks to everybody who was taking the time to sooth the novice ... ;0)
Joh
On Tue, 25 Nov 2003 12:18:35 -0800
Johannes Graumann <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This is a testing/unstable system.
>
> I was just running 'chkrootkit' and came across thi
Thanks to everybody who was taking the time to sooth the novice ... ;0)
Joh
On Tue, 25 Nov 2003 12:18:35 -0800
Johannes Graumann <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This is a testing/unstable system.
>
> I was just running 'chkrootkit' and came across thi
On Tue, 25 Nov 2003, Johannes Graumann wrote:
> Hello,
>
> This is a testing/unstable system.
>
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possibl
On Tue, 25 Nov 2003, Johannes Graumann wrote:
> Hello,
>
> This is a testing/unstable system.
>
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possibl
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possible LKM Trojan installed
I have the same problem.. I believe it's a bug in chkrootkit
Michael
--
To
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possible LKM Trojan installed
I have the same problem.. I believe it's a bug in chkrootkit
Michael
On Tue, 2003-11-25 at 20:18, Johannes Graumann wrote:
[...]
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possible LKM Trojan installed
[...]
> I then went ahea
On Tue, Nov 25, 2003 at 12:18:35PM -0800, Johannes Graumann wrote:
> Hello,
>
> This is a testing/unstable system.
>
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
>
On Tue, 2003-11-25 at 20:18, Johannes Graumann wrote:
[...]
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possible LKM Trojan installed
[...]
> I then went ahea
On Tue, Nov 25, 2003 at 12:18:35PM -0800, Johannes Graumann wrote:
> Hello,
>
> This is a testing/unstable system.
>
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
>
Hello,
This is a testing/unstable system.
I was just running 'chkrootkit' and came across this warning:
> Checking `lkm'... You have 4 process hidden for ps command
> Warning: Possible LKM Trojan installed
I did some reading and made sure the number is not cha
Hello,
This is a testing/unstable system.
I was just running 'chkrootkit' and came across this warning:
> Checking `lkm'... You have 4 process hidden for ps command
> Warning: Possible LKM Trojan installed
I did some reading and made sure the number is not cha
Hello!
Thanks to all for answering!
Kind regards
Matthias
Hi Matthias,
>A reboot does not solve the problem.
>I use an actual sid with kernel 2.4.22 from package
>kernel-source- 2.4.22-3. Before PID 3 are starting
>PID 1 init (of course)
>and
>PID 2 keventd
>
>
>Does this look like a rootkit and what is to do?
Did you see this post?
http://bugs.deb
> Does this look like a rootkit and what is to do?
It's a bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217525
top should display the processes correctly
nico.
Hello!
I have got a problem with chkrootkit, too (refering to http://
lists.debian.org/debian-security/2003/debian-security-200310/msg00204.html):
ai1:# chkrootkit -x lkm
ROOTDIR is `/'
###
### Output of: ./chkproc -v -v
###
PID 3: not in ps output
CWD 3: /
EXE 3: /
PID 4: n
1 - 100 of 140 matches
Mail list logo
