Documentation server security issues
I've been reading the thread about the Debian documentation policy, and...
It seems that many of you aren't taking security seriously enough. Something
to think about:
An HTTP server listening on any TCP port is not secure, even
if you configure it to only allow accesses from the local host.
Explanation: Let's assume that our HTTP server has a security bug that
allows someone to do bad things by sending a cleverly crafted HTTP request
to it (which should be a reasonable assumption; not many TCP servers exist
that haven't had this sort of bug at some time). Now:
- any malicious user on the local host can immediately compromise security
- any user might accidentally trigger the security hole (unlikely)
- a naïve user could run a binary that he got from a malicious "friend" or
from the net that uses the security hole
- (this is perhaps the most serious) A user could view a malicious WWW page
with his browser. This page could have a link (perhaps in an <IMG>, to
autoload it) of the form "http://localhost/..."; that triggers the
security bug.
- if the machine runs a WWW cache, users of the cache could persuade the
cache (that runs on the local host) to create the malicious HTTP request
Making the documentation server listen on a non-standard port gives only a
false sense of security (security through obscurity); anyone who has access
to any Debian system can do a "netstat -a" (for example) and see what the
non-standard port is.
Running the server as nobody (or an equivalent, as opposed to root) helps,
but does not solve the problem. Even nobody can do things like fill /tmp,
forge obscene mail or news, and (especially) break through security holes in
other (setuid) programs to gain root. Basically the system trusts nobody
almost as much as a normal local user -- and most people don't want to hand
out accounts to strangers...
Writing the server carefully and keeping it small helps, but, again, does
not solve the problem. No code is completely bugfree...
(
Note that HTTP is not the thing that makes this insecure; anything that
listens on a TCP port is. It is possible to write an URL that establishes a
TCP connection to any port and sends any data to it, so anyone using a WWW
browser on the Debian host is dangerous. Naturally, firewalls do not help,
since the connection comes from the inside.
I haven't tried it, but I suspect that lprng is insecure in this way; that
is, loading a malicious URL could create a new print job (or compromise
root if lprng's lpd happens to have the right kind of security bug). The
X server should be secure (again, barring bugs in that part of the code),
since an attacker needs to know the Xauthority data to do anything with it.
This is a major reason for why I consider anything that uses TCP and depends
only on IP addresses or network interfaces for authentication insecure (if a
WWW browser or cache runs in a "trusted" place).
)
My point is this: Reading documentation should not need a TCP server. Any
system that does not need to run the server is a win from a security
viewpoint. It would be best the server wasn't needed at all.
If you want to have other machines be able to read your documentation (like
a Debian documentation server in a LAN of different Win95 and Linux boxes),
that's a different issue; then you have to have servers running, and then
you presumably maintain them and accept the potential security problem, just
like with any other (in-company) WWW server. But most people don't need
that, so most people shouldn't need to run the server.
--
-=- Rjs -=- rjs@spider.compart.fi, rjs@lloke.dna.fi
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: