bugtraq - Re: cleartext passwords get into log files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060206112051.GA5190@brucia.ulcc.ac.uk>
Date: Mon, 6 Feb 2006 11:20:52 +0000
From: Ben Wheeler <b.wheeler@...c.ac.uk>
To: innate@....de
Cc: bugtraq@...urityfocus.com
Subject: Re: cleartext passwords get into log files

On Fri, Feb 03, 2006 at 11:53:55AM -0000, innate@....de 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@...host:~> 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