Hi, Thank you for your replies, I was just reading this part of the code and though about crypt(3) failing. I now understand why it is failing but I think this should be patched ASAP ; first I think all libc functions return values should be checked, all the time ; but at least, haproxy should generate an error when loading the configuration file saying the password won't work.
Anyway, thank you very much for your help ; hope this get patched soon ! PS: Any advice on a "less worst" encryption method than md5/sha-1 for those passwords ? crypt(3) says it supports SHA-512 but I'm not sure how it works with the config file. Best regards, Grégoire. ---------------------------------------- > Date: Fri, 29 Aug 2014 14:54:17 +0200 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: Segmentation fault with HTTP Basic Auth > > Hi Grégoire, > (replying from a webmail, not sure the output will be easily readable). > > Le 29/08/2014 13:35, Grégoire Morpain a écrit : >> Hi everyone, >> >> (Please note that I'm not subscribed to the mailing list so I will ask you >> to cc your answers both to me and the mailing list) >> >> I encounter a bug which I think is rather "critical" ; I hope someone can >> help me. >> The problem happens when I try to setup HTTP basic auth on a backend ; here >> is my config example: >> >> https://gist.github.com/wnkz/c2d1c0e6c49fa500658f >> >> userlist L1 >> # user foo insecure-password foo >> user foo password $apr1$Y/Oslz7K$EqwCC6SqzEn35VilLwh/V0 > > The issue is here, see the details at the bottom of the mail. > >> >> backend S3_developer >> acl auth_dev http_auth(L1) >> http-request auth realm Foo unless auth_dev >> redirect scheme https if !{ ssl_fc } >> server S3_developer foo.amazonaws.com:80 >> >> This is the same user ; with the same password (foo) only one is plain-text >> and the other one has been generated with htpasswd. >> I test this setup with curl: >> >> curl --user 'foo:foo' -vL https://test.mydomain/ >> >> When I use the "insecure-password" line ; the test works just fine but when >> I auth with the same user:password with the classic "password" config line >> here is what I get from my curl: >> >> * Empty reply from server >> * Connection #0 to host test.mydomain left intact >> curl: (52) Empty reply from server >> >> And then when I check back on my server ; haproxy process is gone ; nothing >> in the log files but I saw this is dmesg: >> >> [326678.071345] haproxy[7502]: segfault at 0 ip 00007ffff6e8cd56 sp >> 00007fffffffe148 error 4 in libc-2.19.so[7ffff6d4c000+1bb000] >> >> I tried different users, different password and I always get the same result >> so I installed haproxy-dbg and gdb and ran haproxy with gdb. > > This is not as critical as you'd expect ;-) > The segfault happens because your encrypted password is not valid. You are > using a type specific to apache (id apr1) > Use a password supported by crypt() and it won't segfault. > > For example : > $ mkpasswd -m md5 foo > wich will generate an encrypted password with ID 1 (beginning with $1$) > > But I agree a segfault shouldn't happen even with a misconfiguration. > We'll have to verify that the call to crypt() doesn't return NULL, and maybe > we should verify the salt at init. > > -- > Cyril Bonté
