[PATCH 1/2] Allow BusyBox to be built without a list of applet names

Jody Lee Bruchon jody at jodybruchon.com
Sat Apr 30 12:58:46 UTC 2016


On April 30, 2016 8:39:24 AM EDT, Andreas Oberritter <obi at opendreambox.org> wrote:
>On 30.04.2016 09:16, Laurent Bercot wrote:
>>>> The lookup hash isn't collision-free: more than one input string
>>>> points to the same applet.  Normally invalid applet names might
>>>> cause an unexpected one to run
>>>
>>> And this should be a GoodThing (TM) ?
>> 
>>  I'm inclined to vote against this change, because even if the risk
>> is minimal, and even if hashing has important gains, it's just not
>worth
>> it to change a correct, working mechanism to an incorrect one.
>> 
>>  Also, "rwok" is a cool name for a command. Somebody should add a
>"rwok"
>> applet.
>> 
>
>Even worse, consider a busybox binary that someone expects to contain a
>real command like cat or hexdump, which it doesn't. The colliding hash
>of this command could map to a command that accepts the same
>command-line arguments but destroys data, like mkfs.* or rm.
>
>Still even worse, without the list of applet names included in the
>binary, you can't make sure that the applet you're calling actually
>exists without dissecting the binary.
>
>Btw., invalid symlinks of e.g. previous installations of busybox might
>exist in the filesystem. I've seen that in real products. And I've also
>seen scripts call "busybox $cmd" directly many times before.

This problem can be avoided at compile time by hashing all possible applet names in BusyBox and checking for collisions.

I question whether all the extra machinery is worth it in any case.


More information about the busybox mailing list