Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 28 Aug 2010 15:00:39 +0200
From: fijam 7 <>
Subject: Re: A puzzling hash from the past

On Fri, Aug 27, 2010 at 4:16 PM, Solar Designer <> wrote:
> On Fri, Aug 27, 2010 at 10:18:07AM +0200, fijam 7 wrote:
>> I recently analyzed the firmware of a certain discontinued router that
>> I have and managed to extract a cramfs filesystem. There, I found
>> /etc/shadow with a strange hash:
>> user:$1juTFYmn618Y:12086::99999::::
>> To my understanding, a DES hash should have 13 characters in base64
>> digits (including the salt). Any ideas why does it start with a '$'?
> Yes: a program setting the password attempted to use an MD5-based crypt
> hash, so it provided a salt proper for that hash type, but the system's
> libc (or libcrypt) lacked the support, so it produced a DES-based crypt
> hash with the invalid salt of "$1" instead.
>> It appears that the firmware utilized tinylogin 0.80 and uClibc
>> 0.9.26. I had a look at the source but found no clues.
> Different implementations of DES-based crypt(3) process invalid salts
> differently.  I don't know how uClibc in particular processes them.
> JtR implements one of the possible mappings, but if it's not right for
> your target system (for uClibc in this case) then you need to replace
> the '$' character with a "correct" one that maps to the same 6-bit
> value that uClibc maps the '$' to.
> Please refer to these older postings for more detail on the topic:
> Both are linked from:
> * Invalid salts with traditional DES-based crypt(3) (2009/02/28)
>    * Invalid salts - more info on the two known mappings (2008/10/03)
> Since then, I found out that FreeSec - the DES-based crypt(3) code in
> use on free *BSD systems - maps all invalid salt characters simply to
> all zero bits (same as the '.' character).  However, this shouldn't be
> relevant to your case.  I mention it for the sake of completeness (for
> others reading this, including via the mailing list archives).
> I've recently fixed the copy of FreeSec in Owl and in PHP 5.3.2+
> (submitted/committed via a PHP developer) to mimic UFC-crypt instead,
> since obviously mapping all invalid salt characters to just one
> equivalent character would make the common application problems worse
> (for broken apps that feed those invalid salts to crypt() when setting a
> new password, which I imagine is especially common for PHP scripts).
> I hope this response helps, despite of the excessive detail. ;-)
> Alexander

This is a most informative reply, thank you. My Google-fu must have
been weak that day :)


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.