Bug#23661: Security issue when accessing documentation through an http server
Joey Hess <joey@kitenet.net> wrote:
> Martin Stjernholm wrote:
> > Section 4.4 item 2 in the Debian Policy Manual implies that /usr/doc
> > should be made accessible by a web server. It's not mentioned there
> > that it would introduce a security weakness if access to those files
> > isn't restricted to localhost. Almost every package puts files under
> > /usr/doc, which, if access is unrestricted, makes it possible for
> > anyone on the network to do a very detailed scan of the installed
> > software on the computer, including version information in most cases.
> > This sort of info is a great help for an attacker to choose an
> > appropriate method to get into the system.
>
> Interestingly, I brought this up when we formulated the policy, and was
> informed that I was just worrying about "security through obscurity" and it
> wouldn't do any good.
Strictly speaking, that's true. Otoh, making this info so easily
accessible is sort of like betting that every remotely accessible
piece of software on a Debian system doesn't contain a security
glitch. The loosers in this case are all the users that doesn't keep
an eye on the Debian mirrors, CERT, bugtraq and other forums, because
this makes it very easy to scan a large number of computers for known
vulnerabilities and also hide that traffic in perfectly normal http
accesses.
E.g. if someone scans my subnet on the imap and pop ports, some people
will probably notice and alert the admins to track down this clown. If
(s)he scans on the http port, there's a lot less chance someone will
be reading their access log thoroughly enough to notice that /doc is
accessed. The cracker has got the same information to target
vulnerable systems without stirring things up so much.
I can also imagine scenarios with relatively relaxed firewall
configurations where this would help an attacker to get information
about installed software on computers behind the firewall.
Another thing is that questionable software in the contrib section or
from third parties also is likely to put things under /usr/doc, and
thereby "announce" their presence in a way that's probably unintended
by both the package maintainer and the user.
To conclude, it's obvious that this is a help for a cracker. That
being the case, it's a matter of judgement whether the provided
service outweights the lowered security level. It's my strong belief
that choices like this should be made by the user and not stipulated
by a policy. (And in this case the same service can be provided in a
more secure way, so there's no reason not to do so.)
/Martin
--
To UNSUBSCRIBE, email to debian-qa-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: