Re: Documentation server security issues
> On Mon, 7 Jul 1997, Riku Saikkonen wrote:
> > Bernd Eckenfels wrote:
> > >On Jul 7, Riku Saikkonen wrote
> > >> An HTTP server listening on any TCP port is not secure, even
> > >> if you configure it to only allow accesses from the local host.
> > >You can bind on 127.0.0.1, which is then fairly secure.
> > Sorry, but it doesn't help much (as I said later on in the same message).
> > If there's a security hole in the HTTP server, it is trivial to create a
> > WWW page that, when accessed (with almost any browser), will have the
> > browser create a connection to localhost and exploit the security hole.
> > The connection comes from the browser, and thus from 127.0.0.1, so binding
> > there doesn't help.
> Sorry, but if you have local access to the machine, enough to be running a
> web browser then any small security holes in a nobody:nogroup webserver
> will be even more exploitable by the local user sitting at the console.
> Ie, what harm can you do by hacking through a tiny webserver that you
> can't do sitting at the console?
I think I understand what Riku is saying... Lets see if I can explain
it. I can suggest a general form of attack, but I can't give specific
details, because I am not skilled enough.
If I understand it, a successful buffer overflow exploit involves
sending chosen data to the victim, such that it overflows a buffer and
thus executes code chosen by me, instead of the normal code. This
could involve overwriting the return address stored on the stack,
causing other code to be executed with my chosen arguments, etc.
Assuming that a tiny web server is subject to such an attack. All a
black hat would have to do to break into my system is contact my
server, and send it a magic string.
However, if I bind my server to only listen to 127.0.0.1, then he can't
contact my server directly.
But I can. Sitting here at my console, I can 1) contact the server
directly, since I am on the same host, b) exploit any "local" security
holes on my system, even c) execute "ssh localhost -l root" (which I do
reasonably often, as I like to use dselect with an X interface). The
security of my system that is directed towards me serves mostly to keep
me from doing anything stupid. When I need to, I can trivially get
around it, since I know the root password.
So a black hat off site wanting to break into my system via the tiny
documentation web server (which he is assumed to know how to break, if
he can get access) needs to make me an unwilling accomplice to his
So he creates a site containing something I want to see -- perhaps a
COPS package in .deb format (designed to attract security-conscious
Debian users). On the page he has a couple of links that are
attractive. One of which is a link to "http://localhost/carefully-chose
n-data". Of course, it's labeled "COPS" or "Kuang Ice Breaker" (an
"expert system" security tool that used to ship with COPS, don't know
if it still does), so I'll click it.
The next thing that happens is that -I- contact the vulnerable web
server, from within any fire walls, bound sockets, etc, that might
prevent the black hats from breaking in, sending -his- chosen sequence.
The server is cracked, his code gets executed, and in a worst-case
scenario, his crack manages to get root privileges and mails him my ssh
data, so he can log onto my system via a "secure shell", as root.
All because -he- tricked -me- to do his dirty work for him. And he
never even touched my machine.
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> firstname.lastname@example.org .
> Trouble? e-mail to email@example.com .
Buddha Buck firstname.lastname@example.org
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .