GNOME Bugzilla – Bug 732087
md4 implementation (in NTLM auth) has incorrect padding
Last modified: 2014-06-24 17:37:37 UTC
... I think. See RFC1320 S3.1 where it says that '[p]adding is always performed, even if the length of the message is already congruent to 448, modulo 512'. Compare with our code in libsoup, inherited by evolution-data-server and now the OpenConnect VPN client, which does the following: pbytes = (120 - (nbytes % 64)) % 64; In the case of nbytes == 56, this will mean pbytes comes out at zero, when it probably ought to be 64. We later set M[nbytes]=0x80, filling in the first '1' bit in the padding as described in that section of the RFC. And then fill in the length afterwards, starting at M[nbytes + pbytes]. So it looks like the code certainly expects pbytes to be non-zero. Our corporate password rules prevent me from setting a 56-character password in order to test this, but I think we ought to refactor the calculation to effectively add the following after the above-quoted pbytes calculation: if (pbytes == 0) pbytes = 64;
In my copy I've fixed it thus: http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/1d4a71e4 Would be good if I could find someone to actually *test* it though.
Aha, libsamba-util exports an 'mdfour()' function, and the result of using it on the password '1234567890123456789012345678' seems to confirm that my fix is correct. I get 730cd98d3aba72a668361933fa2a9b9c from my new code and from Samba, but 7e751a6a579bb8510309b1df63c0bb56 from the old code (and thus from libsoup and evolution-data-server). Note that the password is converted to UCS2LE, so it's actually a 28-character password which we need to test this. Although that's still too long for our corporate systems to permit, and I still can't test it "in anger".
sure, feel free to commit that patch to libsoup as well
https://git.gnome.org/browse/libsoup/commit/?id=b0918d0a