Comment by zenexer

It looks like DropboxHelperInstaller can be used to extract an arbitrary tarball as root into /Library/DropboxHelperTools, preserving permissions. It takes two arguments: the first is a number (doesn't seem to matter--maybe PPID for callback?) and the second is the bath to the GZIP'd tarball. It seems to require that the tarball have an RSA signature appended to the end, but there are signs that the check may be less than ideal and possible to circumvent.

Output from extracting a Dropbox-signed tarball (in this case, DropboxHelperInstall's own tarball):

    <pid>52229</pid>
    crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
    crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
    mkdir '/Library/DropboxHelperTools' 0755 -> 17
    extracting ./._DropboxHelperInstaller
    extracting DropboxHelperInstaller
    <ok>

Output from attempt to extract a third-party tarball:

    <pid>52286</pid>
    missing magic number
    unable to read_digest
    couldn't verify signature
    <failure> -1

Output from attempt to extract a third-party tarball with the signature copied from a Dropbox tarball:

    <pid>52142</pid>
    crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
    crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
    crypto error while Verifying Signature: bad signature (in rsa routines:INT_RSA_VERIFY)
    couldn't verify signature
    <failure> -1

It's probably worth reverse engineering DropboxHelperInstaller to ensure that the signature check can't be evaded. Even then, I'm not sure I like the idea of anyone with Dropbox's private key being able to install arbitrary setuid binaries on my machine. Given recent events, it's quite possible the private key has already been stolen.