Re: cleartext passwords get into log files
On Fri, Feb 03, 2006 at 11:53:55AM -0000, innate@xxxxxx wrote:
> cleartext passwords get into log files
This is just one of many, many reasons why the system log files in general,
and the auth failure log in particular (if separate), should only be
readable by root (or by an admin group who know the root password anyway).
That is the default situation on every implementation of Unix that
I have ever seen.
Care needs to be taken not to break this security by using Logwatch etc
to mail the contents of logs far and wide.
> from computer security we know one fact for sure:
> never rely on the human concentration and perfection!
...
> badass@badhost:~> grep "illegal user" messages.bak | grep input
> Dec xx 10:10:18 hostname sshd[7793]: input_userauth_request: illegal user
> <clear-text-root-password>
Perhaps someone who is that badly lacking in concentration should not
be trusted with the root password in the first place?
You might also consider disallowing remote root logins as an inherent risk,
requiring admins to login under their own username first and use su(1)
(also makes it easier to see who's done what).
There are legitimate reasons why a sysadmin might want to know the
usernames being used for failed attempts. If you really don't want to
see those messages, you can disable them, or if you must have
lax permissions on /var/log/messages, send them to a separate
secure log instead.
> the username could contain characters that might be interpreted wrong
> from other software. example from log file (caused by sshd again):
Then the other software is broken and needs to be fixed. If it fails
to sanitise log data when necessary, it may have other significant flaws
as well and a code audit would be in order.
> Feb 2 10:20:28 hostname sshd[7419]: Failed keyboard-interactive/pam for
> invalid user d'a<d>;(m)l from ...
>
> just note the characters:
> <> XXS, html injeciton?
> ';() SQL injection?
> '; shell commands?
What kind of software is going to be evaluating a log message
as a shell command or passing it on a commandline??
> just keep in mind that this behavior can be also found in other
> applications. so why not prevent it?!
It is up to the consumer of data to sanitize it in a way that is
appropriate to how it is going to be used. A program which displays
it on a webpage will need to encode HTML entities, whereas one which
puts it in a database will need to escape SQL special chars. Above all,
people who write such programs really need to be non-brain-dead enough
to realise that. It's not up to the producer of data to try to predict
what it will be used for.
Ben