3.0.x: user-password length decoding sometimes wrong?
Hi, ugh. I just updated to 3.0.x from a few minutes ago to be prepared for the MS-CHAP key problem and iOS 9. That seems to work - good. But I have a problem with good old PAP but only for requests originating from one of the clients - and consistently. That client is insanely old and has ancient library versions. So it may well be doing something subtly wrong in the requests it sends; but still, this worked for a FreeRADIUS server versions since a decade. But not in current 3.0.x. What I see coming in (decoded in -X) is: (137) Received Access-Request Id 89 from 158.64.1.50:8010 to 158.64.2.220:1812 length 80 [...] (137) User-Password = "12345678\000\000\000\000\021" That's an 8 char password (12345678 is the equivalent of correct; i.e. redacted in this mail but it otherwise fits). On other clients, the same password comes in as User-Password = "12345678" as expected; a tcpdump between for both clients reveals that the on-the-wire length of User-Password is the same (16 chars net, to account for padding). Current 3.0.x then does SSHA password comparison between what it got and the contents in our DB, and finds that the SSHA hash of the above first string does not match our stored password hash, while the second one does. So it's a Accept/Reject difference and our users are not happy. Now since padded-and-encrypted parsing differences are the exact problem that was fixed for 3.0.9, I suspect that fixing that had a side-effect on PAP password length extraction. It looks like the old client uses \0-then-something-random as padding (I also saw requests with jsut one \0 and then more garbage) while newer clients pad with \0\0\0\0 until the attribute ends. And that the latter works, while the former doesn't :-) I realise that all \0 is what RFC2865 chapter 5.2 mandates as padding text. So, yes, our client is at fault. Still, is there any chance that the server-side parsing could be made a little more forgiving? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Sep 15, 2015, at 11:02 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
ugh. I just updated to 3.0.x from a few minutes ago to be prepared for the MS-CHAP key problem and iOS 9.
That seems to work - good. But I have a problem with good old PAP but only for requests originating from one of the clients - and consistently.
That client is insanely old and has ancient library versions. So it may well be doing something subtly wrong in the requests it sends; but still, this worked for a FreeRADIUS server versions since a decade. But not in current 3.0.x.
I've ran into that, too. With proftpd... I have no idea what they did, but they did something retarded.
What I see coming in (decoded in -X) is:
(137) Received Access-Request Id 89 from 158.64.1.50:8010 to 158.64.2.220:1812 length 80 [...] (137) User-Password = "12345678\000\000\000\000\021"
That's an 8 char password (12345678 is the equivalent of correct; i.e. redacted in this mail but it otherwise fits).
Yes. The client is garbage. In 2.0, the password was searched from the beginning for the first zero character, and truncated there. In 3.0, the password is searched from the end for the first non-zero character, and truncated there.
On other clients, the same password comes in as
User-Password = "12345678"
as expected; a tcpdump between for both clients reveals that the on-the-wire length of User-Password is the same (16 chars net, to account for padding).
That's the encrypted stuff. The problem is that the *decrypted* password is garbage.
I realise that all \0 is what RFC2865 chapter 5.2 mandates as padding text. So, yes, our client is at fault.
Yup. I have NO IDEA how people get random crap at the end of the password. It's crazy. How hard is it to pad the passwords with zeros?
Still, is there any chance that the server-side parsing could be made a little more forgiving?
Not really. The change was made to be compatible with other systems which do sane things. I don't want to fix one thing and break another. My fix for this in 3.0 is as follows. A bit convoluted, but it works. ...... # proftpd sends "password\000\000password" # we want to convert that to "password", # so we do a regex, which will stop at the # first zero. # copy the string with embedded binary zeros update request { Tmp-Octets-0 := &User-Password } # proftp sometimes sends "\000\000\000\000PASS" # which is fucking stupid. Reject it outright. if (Tmp-Octets-0 =~ /^0x00/) { reject } # find the two binary zeros, and copy everything before them # regular expressions will NOT work on strings with embedded # zeros, because the regex libraries do strange things if (Tmp-Octets-0 =~ /^(0x(..)+)0000/) { # get the text BEFORE the zeros update request { Tmp-Octets-0 := "%{1}" } # cast the binary data to a printable string, # and now assign the printable string to the # User-Password attribute... which is a printable # string # if we just assign Tmp-Octets-0 to User-Password, # we get the ASCII version of Tmp-Octets-0, which # is "0xabcdef", and not what we want. # # if we just used the next line without editing # Tmp-Octets-0, then it's string representation # would be "password\000\000password", which is # not what we want. update request { User-Password := "%{string:Tmp-Octets-0}" } } ...
Hi,
Still, is there any chance that the server-side parsing could be made a little more forgiving?
Not really. The change was made to be compatible with other systems which do sane things. I don't want to fix one thing and break another.
Which has now happened for my client ;-) Anyway, fair enough.
My fix for this in 3.0 is as follows. A bit convoluted, but it works.
My fix is to create a time capsule for the client. Clone the RADIUS server VM, revert the clone to the previous version of FreeRADIUS... and tell the client to talk to that server. This incident triggered a somewhat aggressive EOL of the machine in question anyway :-) Greetings, Stefan Winter
participants (3)
-
Alan DeKok -
Stefan Winter -
stefan.winter＠restena.lu