Mailinglist Archive: opensuse-security (232 mails)

< Previous Next >
New SSH vulnerability or what? Users acted as root...
  • From: HG <hg.list@xxxxxxxxx>
  • Date: Mon, 3 Oct 2005 14:35:33 +0300
  • Message-id: <6f133dde0510030435q26d236b8s73e7fb7804eedac@xxxxxxxxxxxxxx>
Hi!

We've had a strange episode with out servers, maybe somebody has seen
something similar.

We first had one of those SSH attacks with invalid users. But then
something that I had not seen before, but probably nothing serious.
Here is some log:

Sep 29 08:15:58 server sshd[20976]: Invalid user andreyd from
::ffff:194.51.214.195
Sep 29 08:15:59 server sshd[20976]: reverse mapping checking
getaddrinfo for 195.192-255.214.51.194.in-addr.arpa failed - POSSIBLE
BREAKIN ATTEMPT!
Sep 29 08:16:00 server sshd[20978]: reverse mapping checking
getaddrinfo for 195.192-255.214.51.194.in-addr.arpa failed - POSSIBLE
BREAKIN ATTEMPT!

But then somewhat after that (half an hour) our /var was suddenly
turned to read-only. So the logs had a gap for about an hour:

Sep 29 09:24:27 syrphus kernel: Additional sense: Invalid field in cdb
Sep 29 09:25:01 syrphus /usr/sbin/cron[22405]: (root) CMD
(/usr/local/bin/bruschedule)
Sep 29 09:25:28 syrphus kernel: st0: Error with sense data: Current
st0: sense key Illegal Request
Sep 29 09:25:28 syrphus kernel: Additional sense: Invalid field in cdb
Sep 29 10:29:15 syrphus syslogd 1.4.1: restart.
Sep 29 10:29:16 syrphus SuSEfirewall2: Warning: FW_MASQ_NETS needs
FW_MASQUERADE set to yes to work!
Sep 29 10:29:16 syrphus nmbd[4536]: [2005/09/29 10:29:16, 0]
libsmb/nmblib.c:send_udp(790)
Sep 29 10:29:16 syrphus nmbd[4536]: Packet send failed to
10.0.0.255(137) ERRNO=Operation not permitted

When something made the /var read-only, we of course had multiple problems.

So the first question is: is there some new hole in SSH? We have SuSE
9.2 with open ssh 3.9p1-3.2 which is the newest one from YOU. And we
do not have any other ports open to the server.

We returned /var and some other stuff from tapes and checked that
nothing really is changed. So we do not believe that anybody got in.
But how else can the /var become read-only... any ideas?

One of the problems that read-only /var caused is that "random" files
changed to be owned by root in users home dirs. These included files
like: .Xauthority, .DCOPserver_*, .ICEauthority as well as others from
.kde. Fixing this was a pain...
As we looked at the situation in data files more carefully, it seemed
that all the files that had been modified during that time were now
owned by root. We think this means that when the users logged in, the
setuid didn't work correctly and the processes were left as root -
i.e. the users were acting as root. Which, if is true, is kind of
scary...

--
HG.

< Previous Next >