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

Jody Lee Bruchon jody at jodybruchon.com
Sat Apr 30 13:36:02 UTC 2016


On April 30, 2016 9:07:42 AM EDT, Tito <farmatito at tiscali.it> wrote:
>
>
>On 04/30/2016 02:58 PM, Jody Lee Bruchon wrote:
>> 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.
>
>Hi,
>is it possible at compile time also to check for every arbitrary string
>
>the user could throw at busybox?

It doesn't matter. If the user is throwing arbitrary command names at BusyBox, the user deserves whatever they get as a result. It is not the job of the program to keep the user from abusing it and being bitten as a result. The proposed feature is a clear "I know what I'm doing" feature (which also means it should default to not being enabled). All that matters is that there are no collisions between known command names in the program. Of course, if the risk is still intolerable, not selecting the option to eliminate the applet name table in the first place eliminates the risk.


More information about the busybox mailing list