I just found a pair of '..' directories in the /lib directory. e2fsck 1.19
didn't even pick up on this!
/lib
4 drwxr-xr-x 19 root root 4096 Jun 9 16:06 ..
4 -rw-rw-r-- 1 root root 27 Jun 9 15:55 ..
How can I get rid of this? I'm on kernel 2.2.19, running on sparc-linux.
--
Hey, they *are* out to get you, but it's nothing personal.
http://www.tahallah.demon.co.uk
On Mon, 16 Jul 2001, Alex Buell wrote:
> I just found a pair of '..' directories in the /lib directory. e2fsck 1.19
> didn't even pick up on this!
>
> /lib
> 4 drwxr-xr-x 19 root root 4096 Jun 9 16:06 ..
> 4 -rw-rw-r-- 1 root root 27 Jun 9 15:55 ..
>
> How can I get rid of this? I'm on kernel 2.2.19, running on sparc-linux.
This is the wrong place to ask this kind of question; you're better of trying
an appropriate newsgroup.
Obviously one of the entries is the real '..', the other is not. If you use
'ls -b' it should show you any non-visible characters (maybe a space, i.e.,
'..\ ').
--
Ignacio Vazquez-Abrams <[email protected]>
On Mon, Jul 16, 2001 at 05:50:12AM +0100, Alex Buell wrote:
> I just found a pair of '..' directories in the /lib directory. e2fsck 1.19
> didn't even pick up on this!
>
> /lib
> 4 drwxr-xr-x 19 root root 4096 Jun 9 16:06 ..
> 4 -rw-rw-r-- 1 root root 27 Jun 9 15:55 ..
>
> How can I get rid of this? I'm on kernel 2.2.19, running on sparc-linux.
ls -aQ
I bet that file has atleasy one space after the "..". The -Q makes ls
enclose the filename in double-quotes.
I'de be worried if this were actually the case, and check the contents
of that file. It's a common way for someone to "hide" files when they
crack a system.
Ben
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` [email protected] -- [email protected] -- [email protected] '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
> I just found a pair of '..' directories in the /lib directory. e2fsck 1.19
> didn't even pick up on this!
> /lib
> 4 drwxr-xr-x 19 root root 4096 Jun 9 16:06 ..
> 4 -rw-rw-r-- 1 root root 27 Jun 9 15:55 ..
>
> How can I get rid of this? I'm on kernel 2.2.19, running on sparc-linux.
first it is not a pair directories, but a directory and a file.
second, are you sure both of the mare just ".." for example
eax /tmp % touch ".. "
eax /tmp % ls -la | grep "\.\."
drwxr-xr-x 23 root root 1024 Sep 16 2000 ..
-rw-rw-r-- 1 adam adam 0 Jul 16 01:09 ..
so use 'od' to see what the filename is composed of:
eax /tmp % ls -la | grep "\.\." | od -a
. . sp nl
--
Adam
http://www.eax.com The Supreme Headquarters of the 32 bit registers
Adam writes:
>> /lib
>> 4 drwxr-xr-x 19 root root 4096 Jun 9 16:06 ..
>> 4 -rw-rw-r-- 1 root root 27 Jun 9 15:55 ..
>>
>> How can I get rid of this? I'm on kernel 2.2.19, running on sparc-linux.
>
> first it is not a pair directories, but a directory and a file.
>
> second, are you sure both of the mare just ".." for example
I don't think so! Look at the "4" on the left. If that is the
inode number from "ls -lia /lib", his disk is seriously messed up.
The inode number for "/lib/.." should be 2, and an inode may not
be shared between a file and a directory.
On Mon, 16 Jul 2001, Adam wrote:
> so use 'od' to see what the filename is composed of:
>
> eax /tmp % ls -la | grep "\.\." | od -a
> . . sp nl
Managed to get at the contents of the miscreant file:
[alex@tahallah]/lib > od ..*
od: ..: Is a directory
0000000 054501 033560 033122 021564 022552 067571 023157 005057
0000020 031501 075110 033157 045067 021561 005000
0000033
Looks like:
YA7p6R#t%joy&o
/3AzH6oJ7#q
Anyone recognize this?
Anyway I've nuked the file now and seems to be OK now. I think this
probably happened whilst I was installing when the power went out.
Thanks for all your help, and I'll force a fsck on reboot now.
--
Hey, they *are* out to get you, but it's nothing personal.
http://www.tahallah.demon.co.uk
On Mon, 16 Jul 2001, Albert D. Cahalan wrote:
> Adam writes:
>
> >> /lib
> >> 4 drwxr-xr-x 19 root root 4096 Jun 9 16:06 ..
> >> 4 -rw-rw-r-- 1 root root 27 Jun 9 15:55 ..
> >>
> >> How can I get rid of this? I'm on kernel 2.2.19, running on sparc-linux.
> >
> > first it is not a pair directories, but a directory and a file.
> >
> > second, are you sure both of the mare just ".." for example
>
> I don't think so! Look at the "4" on the left. If that is the
> inode number from "ls -lia /lib", his disk is seriously messed up.
> The inode number for "/lib/.." should be 2, and an inode may not
> be shared between a file and a directory.
Erm... It _can't_ be an inode number. Something is very fishy there.
a) names are different, otherwise stat() would give the same
results both times it had been called. It didn't.
b) actual inumbers are also different - see above for the reason
why.
c) it might be an effect of getdents() returning crap (i.e.
giving bogus inumbers which ls(1) trusts). However, I don't see any
obvious ways to get corrupted directory tricking getdents() into that
output.
Alex, could you do strace of that? It would clarify the situation.
> On Mon, 16 Jul 2001, Albert D. Cahalan wrote:
>
> > Adam writes:
> >
> > >> /lib
> > >> 4 drwxr-xr-x 19 root root 4096 Jun 9 16:06 ..
> > >> 4 -rw-rw-r-- 1 root root 27 Jun 9 15:55 ..
> > >>
> > >> How can I get rid of this? I'm on kernel 2.2.19, running on sparc-linux.
> > >
> > > first it is not a pair directories, but a directory and a file.
> > >
> > > second, are you sure both of the mare just ".." for example
> >
> > I don't think so! Look at the "4" on the left. If that is the
> > inode number from "ls -lia /lib", his disk is seriously messed up.
> > The inode number for "/lib/.." should be 2, and an inode may not
> > be shared between a file and a directory.
>
> Erm... It _can't_ be an inode number. Something is very fishy there.
I'd say that's a 'ls -las'; both the small file and the directory above take
up a 4k block.
The second is, say, ".. " and the first is just "..".
Nothing interesting at all.
David.
--
David Luyer Phone: +61 3 9674 7525
Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693
Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 2983
http://www.pacific.net.au/ NASDAQ: PCNTF
On Mon, 16 Jul 2001, Alexander Viro wrote:
> Alex, could you do strace of that? It would clarify the situation.
Unfortunately there's no working version of strace for the sparc32-linux
platform. :o( If anyone knows better, I'd be infinitely grateful - mail me
privately.
As it turns out, the extraneous '..' is actually a file. I did a rm ..*,
which left the original .. directory alone but removed the .. file. Did a
e2fsck on reboot, no problems found.
--
Hey, they *are* out to get you, but it's nothing personal.
http://www.tahallah.demon.co.uk
In article <[email protected]>,
Alex Buell <[email protected]> wrote:
>On Mon, 16 Jul 2001, Alexander Viro wrote:
>Unfortunately there's no working version of strace for the sparc32-linux
>platform. :o( If anyone knows better, I'd be infinitely grateful - mail me
>privately.
Standard strace should work just fine on sparc32.
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| [email protected] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
> As it turns out, the extraneous '..' is actually a file. I did a rm ..*,
> which left the original .. directory alone but removed the .. file. Did a
> e2fsck on reboot, no problems found.
>
Yes, good to remove the file, but now my main concern is that your system
may have been compromised as the old ".." dir-not-really file entry may
have other connotations. It is definately a possibility of a cracked
system (as the .. file appears in many new r00tkit type exploits.) i would
do some extensive forensics on the machine in question. are there new
entries in /etc/passwd or /etc/shadow that shouldn't be there?
DISCLAIMER - I am not insisting your machine was compromised, but why be
lax about it? Check the system in every way possible to determine if
someone has cracked and installed a r00tkit on your box. just getting rid
of the single .. entry may not be enough. look for other suspicious
files, keep copies of them before deleting the ones available to the
public in /lib or /usr or whatever, and check out any suspicious files
that were created/modified/accessed in the same window (5 or 6 minuites)
as the double .. entry in /lib
it sounds to me like someone MAY have been trying to replace system lib
files, or even perhaps load malicious kernel code in modules. at my job,
this system would be immediately taken off the 'production line' until a
thorough examination/investigation can be done. check logins around the
ctime of the original .. creation and compare with who was logged in etc
etc.
this may be nothing, it may be a nasty kernel bug, or it may be malicious
hackers attampting to pull the wool over your eyes.
be PARANOID in any situation in which your machine MAY have been
compromised and persue the forensic evidence until you hit a titanium
wall (a brick wall can be easily broken down).
If you have no idea where to go from here, send me email logs of what has
been found and i will give it my best shot at determining whether this is
a kernel bug (which i would assume would've been caught and dealt with by
now), or a nasty attack involving a rootkit, so the 'attackers' can regain
access to the system.
Start with "netstat --inet -a" and see if you find any open ports that
shouldn't be open. That would be the first indication of a rootkit that
allows the rootkitter (person installing the rootkit) to regain access to
the system even after it has been 'locked down'.
rootkits are well know for leaving SEVERAL backdoors so that if one is
found, the attacker still has multiple ways to re-enter and re-penetrate
the system.
----
J Troy Piper
[email protected]
PS - sorry about the FUD slam about 'the evil cracker' but we all know
they DO exist, and the weaker the admin, the easier it is to take
advantage of the systems under the admin's control.
On Mon, Jul 16, 2001 at 07:30:01AM +0100, Alex Buell wrote:
> On Mon, 16 Jul 2001, Alexander Viro wrote:
> > Alex, could you do strace of that? It would clarify the situation.
> Unfortunately there's no working version of strace for the sparc32-linux
> platform. :o( If anyone knows better, I'd be infinitely grateful - mail me
> privately.
> As it turns out, the extraneous '..' is actually a file. I did a rm ..*,
> which left the original .. directory alone but removed the .. file. Did a
> e2fsck on reboot, no problems found.
That's like the old game of adventure when you wave the wand and
it replies "Nothing obvious happens" just before you step into quicksand
(if you waved it an even number of times).
You got problems. There should be a reason for that file and it
ain't good. It ain't good AT ALL. It's a stock "cracker" trick for
hiding something (lame, I know). You need to go over that system with
a fine toothed comb. Boot from secure media, like the LinuxCare BBC
(Bootable Business Card), and sweep that sucker. You can use rpm to
verify the packages to begin with... Don't trust ANY executable on
the system itself.
You HAVE to boot from other media. Some of these suckers have
Linux kernel modules (we'll keep it a little on topic here) like Adore
and KIS that hide processes, connections, services, and files. You can
not trust your kernel if you may have been compromised.
> --
> Hey, they *are* out to get you, but it's nothing personal.
No joke... And I do believe they done got you.
> http://www.tahallah.demon.co.uk
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
On Mon, 16 Jul 2001, Michael H. Warfield wrote:
> You HAVE to boot from other media. Some of these suckers have
> Linux kernel modules (we'll keep it a little on topic here) like Adore
> and KIS that hide processes, connections, services, and files. You can
> not trust your kernel if you may have been compromised.
All I can say this fscking sucks! OK, I'll have to go over the system with
a fine toothed comb and see what's been done to it. Fortunately I'm on a
very slow dialup, so it may not be too troublesome.
> No joke... And I do believe they done got you.
Fscking script kiddies. Oh well, will let you know what I find.
I'm just wondering how they managed to get in given that I never download
binaries and always compile from sources myself. Probably through a
compromised TCP/IP service, I bet.
--
Hey, they *are* out to get you, but it's nothing personal.
http://www.tahallah.demon.co.uk
On Tue, Jul 17, 2001 at 11:26:58AM +0100, Alex Buell wrote:
> I'm just wondering how they managed to get in given that I never download
> binaries and always compile from sources myself. Probably through a
> compromised TCP/IP service, I bet.
That would be a good guess. Without knowing what distribution
you are on and what services you are running, it's impossible to guess.
But there aren't too many out there that don't have something and all
of them have have security updates even for the latest distros. I just
got done researching a couple of DNS worms that are taking advantage
of Bind 8.2.2 and earlier. They probe through DNS only and are massively
scanning the entire IPv4 address space. In three weeks I saw over
30,000 probes into a /19 monitored address space from over 3,000 unique
compromised hosts. At that probing level, it's almost impossible NOT
to get poked by one of those suckers sooner or later. A lot of others
are scanning for port 111 (sun_rpc) or port 515 (lp) and there have been
a raft of problems in ftp. All of these are being automatically scanned
for and even slow dial-ups are going to get hit sooner or later.
It's gotten decidedly MORE hostile out there in the last year or
two with the appearance of these scripted worms, like Ramen, L1on, and TSIG,
that people can just tack more exploits onto and release in the wild.
> --
> Hey, they *are* out to get you, but it's nothing personal.
> http://www.tahallah.demon.co.uk
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
On Tue, 17 Jul 2001, Michael H. Warfield wrote:
> It's gotten decidedly MORE hostile out there in the last year or two
> with the appearance of these scripted worms, like Ramen, L1on, and
> TSIG, that people can just tack more exploits onto and release in the
> wild.
What security sites would you recommend pointing my browser at in order to
check on latest exploits and solutions to get rid of them?
--
Hey, they *are* out to get you, but it's nothing personal.
http://www.tahallah.demon.co.uk
On Tue, Jul 17, 2001 at 01:44:44PM +0100, Alex Buell wrote:
> On Tue, 17 Jul 2001, Michael H. Warfield wrote:
> > It's gotten decidedly MORE hostile out there in the last year or two
> > with the appearance of these scripted worms, like Ramen, L1on, and
> > TSIG, that people can just tack more exploits onto and release in the
> > wild.
> What security sites would you recommend pointing my browser at in order to
> check on latest exploits and solutions to get rid of them?
I generally recommend some of the following:
http://www.securityfocus.com
http://www.securityportal.com
packetstorm.security.com
(Oh, gee, that's now packetstormsecurity.org)
http://www.rootshell.com use to be pretty good, but it's been getting
long in the tooth lately and hasn't changed in ages.
Each of those has additional links to other sites.
Then find the security pages for your distro. RedHat, Turbo,
and most of the other good ones have pages for errata's and security
announcements. Find them and check them out.
Couple of good books out there too... I helped write "Hacking
Linux Exposed" and Bob Toxin has "Real World Linux Security" that you
might find interesting.
> --
> Hey, they *are* out to get you, but it's nothing personal.
>
> http://www.tahallah.demon.co.uk
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Hello All , I am just collecting information on which kernel
versions have worked best wtih a config liek the below & what
I s/b watching out for system wise . Tia , JimL
Main memory size: 128 Mbytes < Will be 1024Mbyts >
1 GenuineIntel processor --+-[ SMP
1 GenuineIntel 2 processor -+
2 16550A serial ports
1 1.44M floppy drive
1 vga+ graphics device
1 keyboard
IDE devices:
ATAPI 48X CD-ROM drive, 128kB Cache
SCSI devices:
HITACHI DK32CJ-36MC <--- Primary drive /
HITACHI DK32CJ-36MC <-+
HITACHI DK32CJ-36MC <---[ in a Software Raid 5 array .
HITACHI DK32CJ-36MC <-+
PCI bus devices:
Host bridge: Unknown vendor CNB30LE PCI Bridge (rev 6).
Host bridge: Unknown vendor CNB30LE PCI Bridge (rev 6).
VGA compatible controller: ATI Unknown device (rev 39).
Ethernet controller: Intel 82557 (rev 8).
ISA bridge: Unknown vendor Unknown device (rev 81).
IDE interface: Unknown vendor Unknown device (rev 0).
USB Controller: Unknown vendor Unknown device (rev 4).
SCSI storage controller: Adaptec AIC-7892 (rev 2).
+----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| [email protected] | DesMoines WA 98198 | only on AXP |
+----------------------------------------------------------------+