Re: [DTrace-devel] [PATCH 03/14] Let USDT module names contain dots

[Nick Alcock <nick.alcock@oracle.com>]

On 4 Jun 2024, Eugene Loh via DTrace-devel stated:

> On 6/4/24 16:42, Kris Van Hees wrote:
>
>> I do not know what to do with this patch.  Either it is correct and then the
>> code should not be #if 0 .. #endif, or it is not, and then the patch should
>> not exist.
>
> I was looking for feedback.  If we're good with the patch, the "#if 0 / #endif" stuff will be removed in the final version of the
> patch.
>
>> Consider that the tst.dlclose1.sh test has output like this:
>> test/unittest/usdt/tst.dlclose1.sh: Running timeout --signal=TERM 41 test/unittest/usdt/tst.dlclose1.sh /home/kvanhees/dtrace-bpf-user/build/dtrace
>> PASS.
>> started pid 68990
>>     ID   PROVIDER            MODULE                          FUNCTION NAME
>> 97026 test_prov68990        livelib.so                                go go
>>
>> So that shows that the module component certain can contain a period (.),
>> so the module component can certainly contain a period (.)
>
> Right.
>
>>   whereas we know
>> that the function component cannot.  Likewise, provider name cannot contain
>> period as far as I know, nor can the probe name.  So, only the module name
>> seems to be an issue.
>
> There are basically two distinct cases here.
>
> In the dof_stash.c case, I note that we are checking a string of the form "%s:%s:%s:%s" to see if it is "." or "..".  That simply
> does not make sense.  I think the indicated code should be removed.

Yes -- that was a mistake. What we want to ensure is that none of the
probe components *consist solely of* "." or "..". This has to happen
before any attempt is made to write them to the DOF stash, and before
any attempt is made to *look them up* in there, to avoid unintended path
traversal.

This is, I'm afraid, a security issue in the presence of potentially
malicious DOF: we can't just do nothing.

-- 
NULL && (void)