Make sure you update linux and ios!

And AIUI only if you have CGI options open on apache.

And bash is the apache default shell, which mostly it isn't.

Reply to
The Natural Philosopher
Loading thread data ...

well its an answer of a sort.

Reply to
The Natural Philosopher

why? it seems pretty clear, wot e said.

Reply to
The Natural Philosopher

OK

Been working on this - have a look here for some proof of concept code in perl:

formatting link

I should be able to make a simple test out of that and go scan my servers.

But the long and the short is:

CGI (and friends) set environment variables from the HTTP headers.

The client controls the headers.

So you can set a server side env var within the web server process (that's handling your request) to anything you like.

If your CGI is bash free, this does not cause a problem.

But!! if your CGI even so much as coughs in the general direction of bash (ie runs it), bash gets the env vars (on my apache setup anyway) and that's all it takes.

The bug causes bash to run the contents of the malformed env var and you can therefore run any command you like on the webserver.

Debian 6 still has no patch through normal channels...

Reply to
Tim Watts

And indeed you are correct.

On debian 6+7 at least apache's shell is /bin/sh which is a symlink to /bin/dash

I had to contrive my test CGI to explicitly call bash.

HOWEVER

dash is the default shell on my Debian 6+7 machines EXCEPT where they were in place dist-upgraded from 5 or earlier - in which case they inherited /bin/bash as the link target.

Also, it will only take someone to have explicitly called /bin/bash in web script - but it should at least be easy to grep -r for that...

My response is to still look at updating bash, but not to panic too much in the meantime.

Of course, if my servers had sensitive data on them, visible to apace, I would have turned them off completely for the intervening period...

Reply to
Tim Watts

Can't the malware use /bin/bash? (is it in bin?)

Reply to
dennis

I don't think it can no.

AIUI it passes control to a script or executable in (typically) usr/lib/cgi-bin

Leastways that's where all the error messages are coming on my server.

Now if they find a bash script in there that's when the trouble starts. I have no scripts at all.

Reply to
The Natural Philosopher

Its all very well knowing its been patched but..

Its like the ssh none random random bits, you may have been compromised before you patched the system. The patch does nothing to detect such compromises and the average user won't have a clue.

Just what should an inexperienced linux user do to check? A windows user can boot a rescue disk and scan for viruses, etc., what's the equivalent for linux?

Reply to
dennis

I concur.

The hack needs 2 things to happen:

1) A poisoned environment variable. This can (in the most common case) happen in any CGI script as CGI by definition loads HTTP headers into environment variables.

Similar technologies like mod_wsgi ar enot affected (I spent this afternoon testing that).

2) Bash needs to be called from the CGI. Doesn't matter how. exec(), system(), result of opening a pipe.

If 1+2, bash can be coerced to running an arbitrary command in the web server context.

If any other shell is the default AND the CGI programmer did not explicitly call bash, the exploit attempt will fail.

Reply to
Tim Watts

Well, the compromise will only be able to affect files the uid/gids of the process had access to. This does not imply the system got rooted.

A very good point - and one that is relevant if you *know* youv'e been hacked...

Use "find" to locate all files with an mtime of less than about 3 days ago. That will be a very small list.

If any binaries are involved, double check with a checksum verification against your package manager if it can (rpm can, debs mostly can).

Reply to
Tim Watts

No.

Reply to
J.B.Treadstone

The hacker can change mtime so that's no use.

Reply to
dennis

They *can* but the never do IME.

The point being, it's well worth doing. Because a positive means you have a case. A negative does not mean you should stop looking, but chances are, you can rest a little easier :)

Reply to
Tim Watts

I run rsync daily and email the result to myself

That tells me what has changed.

Reply to
The Natural Philosopher

Does rsync do a checksum check then? I thought it just looked t dates and times.

Reply to
dennis

En el artículo , Dennis@home escribió:

Yes. Had you bothered to do a 'man rsync', you'd know that.

Reply to
Mike Tomlinson

Yes it can do a checksum - but does not always by default.

Reply to
Tim Watts

My linux boxes don't have man on them. I am not convinced they do checksums either. The whole system only runs in 256M of RAM and the files are a couple of gig each and there are 2 terrabytes so checksumming them every time is going to be very invasive, especially on an arm cpu.

Reply to
dennis

I always assumed so..

You have me slightly worried. Anyway it does look at sizes too.

formatting link

and can be told to look at checksums

basically its expecting a lot of a hacker to take some existing file, not change its length or its date and still manage to do some malware injection.

Reply to
The Natural Philosopher

Unless rsync has been compiled with special options and/or patches it

*will* have the checksum option.

-c will force it on if in doubt.

Reply to
Tim Watts

HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.