Re: [SLUG] Weird login behaviour

[Andrew Bennetts]

On Mon, Feb 28, 2005 at 11:28:24AM +1100, O Plameras wrote:
> Andrew Bennetts wrote:
[...]
> >On Fri, Feb 25, 2005 at 08:16:10PM +1100, O Plameras wrote:
> >
> >>No one can load kernel codes other than loadable kernel modules(LKM)
> >>that are 'enabled'.  If you try to load an LKM that is not configured
> >>the Kernel will not allow it. And because only a dozen or so LKMs are
> >>enabled instead of,  perhaps, hundreds LKMs, it is easy to manage these.
> >
> >You cannot simultaneously have "a dozen or so" kernel modules enabled, and
> >also CONFIG_MODULES=n.
> 
> Yes, I can with CONFIG_ = y

You specifically said "loadable kernel modules(LKM)".  CONFIG_=y does
not make loadable kernel modules.  Loadable kernel modules require loadable
kernel module support, which is the CONFIG_MODULES option.

-Andrew.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[O Plameras]

Andrew Bennetts wrote:
On Mon, Feb 28, 2005 at 10:43:12AM +1100, O Plameras wrote:
[...]
 

It is required that your resulting /usr/src/linux/.config
has:/
..snipped.
CONFIG_MODULES=n
..snipped.
   

This is clearly a different scenario to the one you described in the mail
Steven was replying to:
On Fri, Feb 25, 2005 at 08:16:10PM +1100, O Plameras wrote:
[...]
 

No one can load kernel codes other than loadable kernel modules(LKM) 
that are
'enabled'.  If you try to load an LKM that is not configured the Kernel 
will not
allow it. And because only a dozen or so LKMs are enabled instead of,  
perhaps,
hundreds LKMs, it is easy to manage these.
   

You cannot simultaneously have "a dozen or so" kernel modules enabled, and
also CONFIG_MODULES=n.
 

Yes, I can with CONFIG_ = y
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Andrew Bennetts]

On Mon, Feb 28, 2005 at 10:43:12AM +1100, O Plameras wrote:
[...]
> 
> It is required that your resulting /usr/src/linux/.config
> has:/
> 
> ..snipped.
> CONFIG_MODULES=n
> ..snipped.

This is clearly a different scenario to the one you described in the mail
Steven was replying to:

On Fri, Feb 25, 2005 at 08:16:10PM +1100, O Plameras wrote:
[...]
> 
> No one can load kernel codes other than loadable kernel modules(LKM) 
> that are
> 'enabled'.  If you try to load an LKM that is not configured the Kernel 
> will not
> allow it. And because only a dozen or so LKMs are enabled instead of,  
> perhaps,
> hundreds LKMs, it is easy to manage these.

You cannot simultaneously have "a dozen or so" kernel modules enabled, and
also CONFIG_MODULES=n.

-Andrew.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[O Plameras]

Steve Kowalik wrote:
That isn't the point at all. A kernel module can still be loaded if it
isn't shipped with the kernel, and indeed, the kind of module that
allows people to break machines would be anyway.
 

No. This is not right.
I strongly suggest you try the ff procedure which can be replicated.
1.  Let's build a Linux kernel for a firewall with two (2) ethernet 
interfaces.
I specify firewall so you will need just a few modules.
2. Get the source codes for a stock kernel, say, version 2.6.9.
3.  Install the source codes in /usr/src/linux
4.  Copy your current 'CONFIG' file (usually located in /boot), say,
/boot/config-2.6.9 into /usr/src/linux/.config.
5.  Whilst in the directory /usr/src/linux run this:
# make oldconfig
6. Next run this:
# make menuconfig
and configure only the functionalities to get the kernel up and
running as a firewall, no more and no less. /

It is required that your resulting /usr/src/linux/.config
has:/
..snipped.
CONFIG_MODULES=n
..snipped.
7. Now, run this:
#make modules && make && make modules_install && make install
8. Reboot with the just compiled kernel.
9. Try loading any of your LKM that you made up and compiled somewhere
else that you copied in your just rebooted system.
10. Tell us whether you are able to load your LKM in 9.
*/I  CANNOT/*.

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Steve Kowalik]

On Fri, 25 Feb 2005 20:16:10 +1100, O Plameras uttered
> No one can load kernel codes other than loadable kernel modules(LKM) 
> that are
> 'enabled'.  If you try to load an LKM that is not configured the Kernel 
> will not
> allow it. And because only a dozen or so LKMs are enabled instead of,  
> perhaps,
> hundreds LKMs, it is easy to manage these.
> 
That isn't the point at all. A kernel module can still be loaded if it
isn't shipped with the kernel, and indeed, the kind of module that
allows people to break machines would be anyway.

Cheers,
-- 
Steve
English is about as pure as a cribhouse whore. We don't just borrow
words; on occasion, English has pursued other languages down alleyways
to beat them unconscious and rifle their pockets for new vocabulary."
 - James D. Nicoll, resident of rec.arts.sf.written
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[O Plameras]

Angus Lees wrote:
At Thu, 24 Feb 2005 22:37:42 +1100, Oscar Plameras wrote:
 

With my firewalls and other security critical servers, I require
recompiling kernels by removing all UNUSED and REDUNDANT modules as
   

'Removing' in the context of re-compiling kernel means 'disabling' 
kernel modules
through a process such as kernel configuration. It is NOT removing the 
physical
binary files. This is done with the command 'menuconfig' before running 
a series
of 'make' commands.

BTW, the production OS has source codes, headers, and compilers removed so
there is no chance the hacker may re-configure and re-compile.
part of the audit process so, when I got a problem such as the one
illustrated above, I ONLY need to examine a few modules instead of
TONS of them.
   

Of course, nasty kernel code can be loaded and then the file
containing that code deleted.  (ie: modules on disk really have no
relation to loaded modules).  So this only really adds a level of
inconvenience to hackers - assuming they wanted one of the standard
modules (and it takes up less disk space if thats important too).
 

No one can load kernel codes other than loadable kernel modules(LKM) 
that are
'enabled'.  If you try to load an LKM that is not configured the Kernel 
will not
allow it. And because only a dozen or so LKMs are enabled instead of,  
perhaps,
hundreds LKMs, it is easy to manage these.

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Angus Lees]

At Thu, 24 Feb 2005 22:37:42 +1100, Oscar Plameras wrote:
> With my firewalls and other security critical servers, I require
> recompiling kernels by removing all UNUSED and REDUNDANT modules as
> part of the audit process so, when I got a problem such as the one
> illustrated above, I ONLY need to examine a few modules instead of
> TONS of them.

Of course, nasty kernel code can be loaded and then the file
containing that code deleted.  (ie: modules on disk really have no
relation to loaded modules).  So this only really adds a level of
inconvenience to hackers - assuming they wanted one of the standard
modules (and it takes up less disk space if thats important too).

-- 
 - Gus

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[O Plameras]

[EMAIL PROTECTED] wrote:
On Thu, 24 Feb 2005 19:22:22 +1100, O Plameras
<[EMAIL PROTECTED]> wrote:
 

Ff. is a sample of positvie result showing possible
Loadable Kernel Module (LKM) Trojan:
[EMAIL PROTECTED] chkrootkit-0.45]# ./chkrootkit
.snipped.
Searching for ESRK rootkit default files... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... You have 3 process hidden for readdir command
You have 3 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installed
Checking `rexedcs'... not found
Checking `sniffer'... br0: not promisc and no PF_PACKET sockets
Checking `w55808'... not infected
.snipped..
   

Is this a recent version? chkrootkit used not to handle 2.6's new way of
"hiding" theads and reportted them as hidden process just like above.
Apparently recent versions know how to handle this.
 


My Linux = 2.6.9-rc3-bk1. As a matter of fact  I have all sorts of Linux 
versions
that I run chkrootkit with no problems.

My chkrootkit = 0.45
My ToolBoxes are in CDs in a variety of VERSIONS including 'chkrootkit'
and are offlined when not used. I also maintained copies in CDs of my 
production
OS with cryptographic checksums which is taken just before it is put online.

With my firewalls and other security critical servers, I require 
recompiling kernels by
removing all UNUSED and REDUNDANT modules as part of the audit process so,
when I got a problem such as the one illustrated above, I ONLY need to 
examine a few
modules instead of TONS of them. As well I only need to generate fewer 
cryptographic
checksums albeit faster because I am dealing with a lot fewer files as 
my security benchmarks 
than when I have the  stock kernels. In my view, 'chkrootkit' is mainly 
useful when you
have checksumed a 'virgin' production OS.

I do not leave any crowbar lying around when I park my car, so it was said.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[amos]

On Thu, 24 Feb 2005 19:22:22 +1100, O Plameras
<[EMAIL PROTECTED]> wrote:
> Ff. is a sample of positvie result showing possible
> Loadable Kernel Module (LKM) Trojan:
> 
> [EMAIL PROTECTED] chkrootkit-0.45]# ./chkrootkit
> 
> .snipped.
> Searching for ESRK rootkit default files... nothing found
> Searching for anomalies in shell history files... nothing found
> Checking `asp'... not infected
> Checking `bindshell'... not infected
> Checking `lkm'... You have 3 process hidden for readdir command
> You have 3 process hidden for ps command
> chkproc: Warning: Possible LKM Trojan installed
> Checking `rexedcs'... not found
> Checking `sniffer'... br0: not promisc and no PF_PACKET sockets
> Checking `w55808'... not infected
> .snipped..

Is this a recent version? chkrootkit used not to handle 2.6's new way of
"hiding" theads and reportted them as hidden process just like above.
Apparently recent versions know how to handle this.

Cheers,

--Amos
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[O Plameras]

Ben de Luca wrote:

BTW - I keep being surprised to hear even security experts advise to run
"chkrootkit" (and I'm not a security expert or a paranoid user/admin) 
- if a
machine was hacked then there is a good chance that "chkrootkit" would
also be hacked to disguise the rootkit, wouldn't it?  (it's not far 
fetched -
see viruses attacking anti-virus programs).

Its just another tool in the box, I have never seen it return a 
positive result. Thats part of the fun of running it im waiting to see 
it do so.

Hi Ben,
Ff. is a sample of positvie result showing possible
Loadable Kernel Module (LKM) Trojan:
[EMAIL PROTECTED] chkrootkit-0.45]# ./chkrootkit
.snipped.
Searching for ESRK rootkit default files... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... You have 3 process hidden for readdir command
You have 3 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installed
Checking `rexedcs'... not found
Checking `sniffer'... br0: not promisc and no PF_PACKET sockets
Checking `w55808'... not infected
.snipped..
O Plameras

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Ben de Luca]

BTW - I keep being surprised to hear even security experts advise to 
run
"chkrootkit" (and I'm not a security expert or a paranoid user/admin) 
- if a
machine was hacked then there is a good chance that "chkrootkit" would
also be hacked to disguise the rootkit, wouldn't it?  (it's not far 
fetched -
see viruses attacking anti-virus programs).

Its just another tool in the box, I have never seen it return a 
positive result. Thats part of the fun of running it im waiting to see 
it do so.




Cheers,
--Amos
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Mike MacCana]

[EMAIL PROTECTED] wrote:
On Thu, 24 Feb 2005 12:12:31 +1100, Mike MacCana
<[EMAIL PROTECTED]> wrote:
 

[EMAIL PROTECTED] wrote:
   

On Wed, 23 Feb 2005 17:12:02 +1100, Mike MacCana
<[EMAIL PROTECTED]> wrote:
 

[EMAIL PROTECTED] wrote:

   

On Wed, 23 Feb 2005 13:08:30 +1100, Mike MacCana > That said, even if
you don't have the second item, try anyway

 

- if it says that, say, netstat has a bad MD5, then you know its bad
- if it doesn't, then be aware there still could be a chance that the
file has been trojaned.

   

Do you realize that this is a completely useless test?

 

No I don't 'realize' that, because you haven't proven it to be true.

   

Whatever the outcome of the test is - you will (or at least *should*) keep
suspecting that binary.

 

As I've said, if the test says the binary is bad, then the binary is
very much likely going to be bad.
Prove me wrong.
   

The point I'm trying to make is that this test is not going to tell you
anything new about the testted files - whether it says that they are
OK or not you can't trust them, so what's the point of doing it?
 

If they say they are not OK, you *know* they are not OK, and can stop
wondering if you've been hacked.
   

You are right on that half of the options. But if they say that the files are OK then will you "stop wondering if you've
ben hacked"? 

No, you should continue investigating.
As I said in the first place, before you decided to argue about it.
Mike
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[amos]

On Thu, 24 Feb 2005 12:12:27 +1100, Mike MacCana
<[EMAIL PROTECTED]> wrote:
> > why do you trust the back up of the RPM database?
> 
> Because its on a CDR, and you've made one each week, hopefully from a
> date before your machine got attacked.

OK, you would be right on this if you could trust the CD (e.g. get it
from another site which you trust, but not from your own machine which
you don't know when it was hacked).

> 
> Just like tripwire (but recording more stuff).

That's a shortcoming of tripwire as well - unless you can compare
to data you can 100% trust (i.e. that didn't have a window of opportunity
to be hacked before you burned the checksums).

BTW - I keep being surprised to hear even security experts advise to run
"chkrootkit" (and I'm not a security expert or a paranoid user/admin) - if a
machine was hacked then there is a good chance that "chkrootkit" would
also be hacked to disguise the rootkit, wouldn't it?  (it's not far fetched -
see viruses attacking anti-virus programs).

Cheers,

--Amos
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Mike MacCana]

Ben de Luca wrote:
On 23/02/2005, at 5:12 PM, Mike MacCana wrote:
[EMAIL PROTECTED] wrote:
On Wed, 23 Feb 2005 13:08:30 +1100, Mike MacCana > That said, even if
you don't have the second item, try anyway
- if it says that, say, netstat has a bad MD5, then you know its bad
- if it doesn't, then be aware there still could be a chance that the
file has been trojaned.
Do you realize that this is a completely useless test?
No I don't 'realize' that, because you haven't proven it to be true.
why do you trust the back up of the RPM database?
Because its on a CDR, and you've made one each week, hopefully from a 
date before your machine got attacked.

Just like tripwire (but recording more stuff).
Mike
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[amos]

On Wed, 23 Feb 2005 17:12:02 +1100, Mike MacCana
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> 
> >On Wed, 23 Feb 2005 13:08:30 +1100, Mike MacCana > That said, even if
> >you don't have the second item, try anyway
> >
> >
> >> - if it says that, say, netstat has a bad MD5, then you know its bad
> >> - if it doesn't, then be aware there still could be a chance that the
> >>file has been trojaned.
> >>
> >>
> >
> >Do you realize that this is a completely useless test?
> >
> >
> No I don't 'realize' that, because you haven't proven it to be true.
> 
> >Whatever the outcome of the test is - you will (or at least *should*) keep
> >suspecting that binary.
> >
> >
> As I've said, if the test says the binary is bad, then the binary is
> very much likely going to be bad.
> 
> Prove me wrong.

The point I'm trying to make is that this test is not going to tell you
anything new about the testted files - whether it says that they are
OK or not you can't trust them, so what's the point of doing it?

The above is actually a sample from first year Logic 101 - "how
do you tell a lier from a trush-saier? If you ask him "are you a lier"
and he says "no" then it didn't add any new information to you
because both a truth-sayer and a lier will always say "no" to
this question.

Similar thing happens here:

1. If the test tells you that you can't trust a file then you probably
can't trust the file.
2. If the test tells you that you can trust the file you still can't
trust the file because you can't trust the test itself since the
tool you use to run this test could have been tempered with too.

See my point now?

Cheers,

--Amos
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Ben de Luca]

On 23/02/2005, at 5:12 PM, Mike MacCana wrote:
[EMAIL PROTECTED] wrote:
On Wed, 23 Feb 2005 13:08:30 +1100, Mike MacCana > That said, even if
you don't have the second item, try anyway
- if it says that, say, netstat has a bad MD5, then you know its bad
- if it doesn't, then be aware there still could be a chance that the
file has been trojaned.
Do you realize that this is a completely useless test?
No I don't 'realize' that, because you haven't proven it to be true.
why do you trust the back up of the RPM database?
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Mike MacCana]

[EMAIL PROTECTED] wrote:
On Wed, 23 Feb 2005 13:08:30 +1100, Mike MacCana > That said, even if
you don't have the second item, try anyway
 

- if it says that, say, netstat has a bad MD5, then you know its bad
- if it doesn't, then be aware there still could be a chance that the
file has been trojaned.
   

Do you realize that this is a completely useless test?
 

No I don't 'realize' that, because you haven't proven it to be true.
Whatever the outcome of the test is - you will (or at least *should*) keep
suspecting that binary.
 

As I've said, if the test says the binary is bad, then the binary is 
very much likely going to be bad.

Prove me wrong.
Mike
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[amos]

On Wed, 23 Feb 2005 13:08:30 +1100, Mike MacCana > That said, even if
you don't have the second item, try anyway
>  - if it says that, say, netstat has a bad MD5, then you know its bad
>  - if it doesn't, then be aware there still could be a chance that the
> file has been trojaned.

Do you realize that this is a completely useless test?
Whatever the outcome of the test is - you will (or at least *should*) keep
suspecting that binary.

("If you are going to do the same thing whatever the answer is given to
a question, don't bother to ask the question" - paraphrasing an old verb).

>From the error messages reported by the original poster I suspect that:

1. Something like a very basic shared library or dynamic loader or a shell
was tempered with, the tempering was done badly and causes the
command-line to be screwed up.
2. He better backup his data (no programs, just data) and re-install the system
from scratch.

The list of suid programs he listed, BTW, look reasonable to me and does not
indicate a break in by itself.

Cheers,

--Amos
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Mike MacCana]

Ben de Luca wrote:
Is the second shell you run a login shell?
there is an app called chkroot kit, I have never seen it return a 
positive, machines its been obvious on the machines that were rooted 
that I have seen that they were.

If you run the rpms verify functions there is no guarentee that it 
hasn't been compromised as well. 
There is if:
- You use a known good copy of rpm (boot off the CD in rescue mode).
- You use a known good copy of the rpm database (--dbpath 
/mnt/cdrom/rpmdatabasebackup).

That said, even if you don't have the second item, try anyway
- if it says that, say, netstat has a bad MD5, then you know its bad
- if it doesn't, then be aware there still could be a chance that the 
file has been trojaned.

Mike
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Ben de Luca]

Is the second shell you run a login shell?
there is an app called chkroot kit, I have never seen it return a 
positive, machines its been obvious on the machines that were rooted 
that I have seen that they were.

If you run the rpms verify functions there is no guarentee that it 
hasn't been compromised as well. Things to look for a process that 
shouldn't be running, process from strange places running (eg from 
/tmp/). check password files for new users, or users who shouldn't have 
passwords that do. If your running web servers its worth looking for 
new cgi. Check that mail services are running in a way you would 
expect. if you can compare md5's with a known good machine it can be 
useful.

Thats not a definitive list.


On 23/02/2005, at 7:16 AM, Howard Lowndes wrote:
On Tue, 2005-02-22 at 22:07, Robert Holmes wrote:
Dear list,
When logging in to my hitherto trusty SuSE8.2 after issuing the 
password
nothing happens for a few seconds, then the screen fills with:

/bin/grep: too many arguments
I've seen the above before - on a rootkitted machine.
/bin/ls: too many arguments
/bin/manpath: too many arguments
/bin/sed: too many arguments
etc
I can kill the process with ctrl c; but then get a bash prompt:
-bash2.05$
(the minus sign is intentional)
I can spawn a bash shell from this prompt (with /bin/bash), where my 
'normal'
prompt appears.

The output of ps ax, shows there is indeed a stopped process called 
-bash.  If
I kill it I'm back to the login prompt.

This behaviour is for runlevels 2,3 & 5 (I guess, 'cause after the 
xdm login
the system hangs).

Any clues as to what's going on here?
I'm rather suspicious, & in rescue mode found a few setuid & setgid 
files on
my system, as recommended in:
www.cert.org/tech_tips/intruder_detection_checklist.html

Should all these be setuid (ignore the HD, I mounted the drive here 
in rescue
mode)?

/HD/bin/su
/HD/bin/ping
/HD/bin/eject
/HD/bin/mount
/HD/bin/ping6
/HD/bin/umount
/HD/opt/kde3/bin/fileshareset
/HD/opt/kde3/bin/kgrantpty
/HD/opt/kde3/bin/artswrapper
/HD/opt/kde3/bin/kcheckpass
/HD/opt/kde3/bin/kpac_dhcp_helper
/HD/usr/bin/at
/HD/usr/bin/rcp
/HD/usr/bin/rsh
/HD/usr/bin/ssh
/HD/usr/bin/bing
/HD/usr/bin/chfn
/HD/usr/bin/chsh
/HD/usr/bin/sudo
/HD/usr/bin/crontab
/HD/usr/bin/chage
/HD/usr/bin/mandb
/HD/usr/bin/ziptool
/HD/usr/bin/rcp
/HD/usr/bin/rsh
/HD/usr/bin/ssh
/HD/usr/bin/bing
/HD/usr/bin/chfn
/HD/usr/bin/chsh
/HD/usr/bin/sudo
/HD/usr/bin/crontab
/HD/usr/bin/chage
/HD/usr/bin/mandb
/HD/usr/bin/ziptool
/HD/usr/bin/ncplogin
/HD/usr/bin/ncpmount
/HD/usr/bin/expiry
/HD/usr/bin/ncpmap
/HD/usr/bin/newgrp
/HD/usr/bin/ntping
/HD/usr/bin/passwd
/HD/usr/bin/gpasswd
/HD/usr/bin/rlogin
/HD/usr/bin/nwsfind
/HD/usr/bin/ncpumount
/HD/usr/bin/cdrecord
/HD/usr/lib/news/bin/inndstart
/HD/usr/lib/news/bin/startinnfeed
/HD/usr/lib/pt_chown
/HD/usr/sbin/isdnctrl
/HD/usr/sbin/suexec
/HD/usr/sbin/plpnfsd
/HD/usr/X11R6/bin/dga
/HD/usr/X11R6/bin/v4l-conf
/HD/usr/X11R6/bin/XFree86
Regards, Robert
--
Howard.
LANNet Computing Associates;
Your Linux people 
--
"When you just want a system that works, you choose Linux;
when you want a system that just works, you choose Microsoft."
--
"Flatter government, not fatter government;
Get rid of the Australian states."
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[Howard Lowndes]

On Tue, 2005-02-22 at 22:07, Robert Holmes wrote:
> Dear list,
> 
> When logging in to my hitherto trusty SuSE8.2 after issuing the password 
> nothing happens for a few seconds, then the screen fills with:
> 
> /bin/grep: too many arguments

I've seen the above before - on a rootkitted machine.

> /bin/ls: too many arguments
> /bin/manpath: too many arguments
> /bin/sed: too many arguments 
> 
> etc
> 
> I can kill the process with ctrl c; but then get a bash prompt:
> 
> -bash2.05$
> 
> (the minus sign is intentional) 
> 
> I can spawn a bash shell from this prompt (with /bin/bash), where my 'normal' 
> prompt appears.
> 
> The output of ps ax, shows there is indeed a stopped process called -bash.  
> If 
> I kill it I'm back to the login prompt.
> 
> This behaviour is for runlevels 2,3 & 5 (I guess, 'cause after the xdm login 
> the system hangs).
> 
> Any clues as to what's going on here?
> 
> I'm rather suspicious, & in rescue mode found a few setuid & setgid files on 
> my system, as recommended in: 
> www.cert.org/tech_tips/intruder_detection_checklist.html
> 
> Should all these be setuid (ignore the HD, I mounted the drive here in rescue 
> mode)?
> 
> /HD/bin/su
> /HD/bin/ping
> /HD/bin/eject
> /HD/bin/mount
> /HD/bin/ping6
> /HD/bin/umount
> /HD/opt/kde3/bin/fileshareset
> /HD/opt/kde3/bin/kgrantpty
> /HD/opt/kde3/bin/artswrapper
> /HD/opt/kde3/bin/kcheckpass
> /HD/opt/kde3/bin/kpac_dhcp_helper
> /HD/usr/bin/at
> /HD/usr/bin/rcp
> /HD/usr/bin/rsh
> /HD/usr/bin/ssh
> /HD/usr/bin/bing
> /HD/usr/bin/chfn
> /HD/usr/bin/chsh
> /HD/usr/bin/sudo
> /HD/usr/bin/crontab
> /HD/usr/bin/chage
> /HD/usr/bin/mandb
> /HD/usr/bin/ziptool
> /HD/usr/bin/rcp
> /HD/usr/bin/rsh
> /HD/usr/bin/ssh
> /HD/usr/bin/bing
> /HD/usr/bin/chfn
> /HD/usr/bin/chsh
> /HD/usr/bin/sudo
> /HD/usr/bin/crontab
> /HD/usr/bin/chage
> /HD/usr/bin/mandb
> /HD/usr/bin/ziptool
> /HD/usr/bin/ncplogin
> /HD/usr/bin/ncpmount
> /HD/usr/bin/expiry
> /HD/usr/bin/ncpmap
> /HD/usr/bin/newgrp
> /HD/usr/bin/ntping
> /HD/usr/bin/passwd
> /HD/usr/bin/gpasswd
> /HD/usr/bin/rlogin
> /HD/usr/bin/nwsfind
> /HD/usr/bin/ncpumount
> /HD/usr/bin/cdrecord
> /HD/usr/lib/news/bin/inndstart
> /HD/usr/lib/news/bin/startinnfeed
> /HD/usr/lib/pt_chown
> /HD/usr/sbin/isdnctrl
> /HD/usr/sbin/suexec
> /HD/usr/sbin/plpnfsd
> /HD/usr/X11R6/bin/dga
> /HD/usr/X11R6/bin/v4l-conf
> /HD/usr/X11R6/bin/XFree86
> 
> Regards, Robert
-- 
Howard.
LANNet Computing Associates;
Your Linux people 
--
"When you just want a system that works, you choose Linux;
when you want a system that just works, you choose Microsoft."
--
"Flatter government, not fatter government;
Get rid of the Australian states."


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Weird login behaviour

[mlh]

At a quick glance, they _seem_ to be ok.

but run rpm --verify --root /HD
and/or a chkrootkit type thing.

Is the machine exposed to the net?

Is it regularly updated?

Matt
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] Weird login behaviour

[Robert Holmes]

Dear list,

When logging in to my hitherto trusty SuSE8.2 after issuing the password 
nothing happens for a few seconds, then the screen fills with:

/bin/grep: too many arguments
/bin/ls: too many arguments
/bin/manpath: too many arguments
/bin/sed: too many arguments 

etc

I can kill the process with ctrl c; but then get a bash prompt:

-bash2.05$

(the minus sign is intentional) 

I can spawn a bash shell from this prompt (with /bin/bash), where my 'normal' 
prompt appears.

The output of ps ax, shows there is indeed a stopped process called -bash.  If 
I kill it I'm back to the login prompt.

This behaviour is for runlevels 2,3 & 5 (I guess, 'cause after the xdm login 
the system hangs).

Any clues as to what's going on here?

I'm rather suspicious, & in rescue mode found a few setuid & setgid files on 
my system, as recommended in: 
www.cert.org/tech_tips/intruder_detection_checklist.html

Should all these be setuid (ignore the HD, I mounted the drive here in rescue 
mode)?

/HD/bin/su
/HD/bin/ping
/HD/bin/eject
/HD/bin/mount
/HD/bin/ping6
/HD/bin/umount
/HD/opt/kde3/bin/fileshareset
/HD/opt/kde3/bin/kgrantpty
/HD/opt/kde3/bin/artswrapper
/HD/opt/kde3/bin/kcheckpass
/HD/opt/kde3/bin/kpac_dhcp_helper
/HD/usr/bin/at
/HD/usr/bin/rcp
/HD/usr/bin/rsh
/HD/usr/bin/ssh
/HD/usr/bin/bing
/HD/usr/bin/chfn
/HD/usr/bin/chsh
/HD/usr/bin/sudo
/HD/usr/bin/crontab
/HD/usr/bin/chage
/HD/usr/bin/mandb
/HD/usr/bin/ziptool
/HD/usr/bin/rcp
/HD/usr/bin/rsh
/HD/usr/bin/ssh
/HD/usr/bin/bing
/HD/usr/bin/chfn
/HD/usr/bin/chsh
/HD/usr/bin/sudo
/HD/usr/bin/crontab
/HD/usr/bin/chage
/HD/usr/bin/mandb
/HD/usr/bin/ziptool
/HD/usr/bin/ncplogin
/HD/usr/bin/ncpmount
/HD/usr/bin/expiry
/HD/usr/bin/ncpmap
/HD/usr/bin/newgrp
/HD/usr/bin/ntping
/HD/usr/bin/passwd
/HD/usr/bin/gpasswd
/HD/usr/bin/rlogin
/HD/usr/bin/nwsfind
/HD/usr/bin/ncpumount
/HD/usr/bin/cdrecord
/HD/usr/lib/news/bin/inndstart
/HD/usr/lib/news/bin/startinnfeed
/HD/usr/lib/pt_chown
/HD/usr/sbin/isdnctrl
/HD/usr/sbin/suexec
/HD/usr/sbin/plpnfsd
/HD/usr/X11R6/bin/dga
/HD/usr/X11R6/bin/v4l-conf
/HD/usr/X11R6/bin/XFree86

Regards, Robert

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html