[DTrace-devel] [PATCH 03/14] Let USDT module names contain dots
Nick Alcock
nick.alcock at oracle.com
Fri Jun 7 18:48:05 UTC 2024
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)
More information about the DTrace-devel
mailing list