The Tech Behind Dropbox’s New User Experience on Mobile, Part 2 | Hacker News Reader

The Tech Behind Dropbox’s New User Experience on Mobile, Part 2

tech.dropbox.com

81 pointstweakz33 comments

I'm surprised you can sign an executable, then modify it while preserving the validity of the signature, as I always though this is exactly what code signing is meant to prevent. Can anyone who knows more about this than me (a low bar!) explain whether this is a flaw in the signing mechanism or is actually okay?

From the article: "Our custom tool allows us to create an unverified section of the binary in a way that is compliant with the Authenticode spec. We make the tag buffer an unverified section so that the tag buffer can change without having to re-sign the binary."

So they sign 90% of the executable, but 10% of it is unsigned.

More importantly, what good is a code-signed executable when that executable can simply download a payload from the internet like this Dropbox installer does? Code signing seems like a feel-good mechanism for users. Yeah, we guarantee that the executable that you downloaded was signed by a legitimate entity but once you run it, good luck. This type of "meta installer" seems ripe for exploitation. Unscrupulous entities create a legit signed app that later downloads a malicious payload; legitimate distributors might also find themselves to be the target of attackers who want to alter that downloadable payload.

I think the point of code signing is to ensure that the program was really written by Dropbox, so _if_ you trust Dropbox you should trust the program. That trust should definitely include both Dropbox's good intentions and their competency to prevent their payload system from being subverted.

>That trust should definitely include both Dropbox's good intentions and their competency to prevent their payload system from being subverted.

Only a fool would, after their actions of the past year, still believe this company has good intentions or that their payload system hasn't already been totally compromised (with their cooperation, no less).

Signing doesn't imply you are "legit", at least not much - it requires ID verification but in the absence of any hard rules about what's acceptable that's only useful in the most egregious cases, and anyway you can still run unsigned binaries.

Signing is mostly useful to help reduce anti-virus false positives. AV systems learn binary reputations just like spam filters do. It doesn't matter if the app goes off and downloads another program for this purpose - that's an implementation detail that doesn't impact whether the app is malicious or not.

Neat. Just tried downloading an installer and figured out that it's using the unauthenticatedAttributes structure of the Authenticode signature.

These attributes are not part of the signedAttributes which is used to actually authenticate the signature. A quick dump of the asn.1 structure of the authenticode signature block from my installer shows that right after the timestamp extension is a new object with a private OID (presumably assigned to dropbox for this purpose) that includes a unique string.

6519 11: OBJECT IDENTIFIER '1 3 6 1 4 1 42921 1 2 1' 6532 1049: SET { 6536 1045: UTF8String : 'Dropbox-Installer-Id:DBPREAUTH::msie::xxxx..........................................'

Interesting hack, kudos!

Fascinating stuff, but was this a problem in need of a solution? Was Dropbox seeing that many issues with people running the install on their local machine? Were they able to differentiate between those who felt the install was a hassle versus those who simply opted to not install it?

There are a lot of places that we were seeing users drop off the radar when trying to install. Through a combination of logging analytics and user studies we figured out what the main problems were and designed this flow to solve them. (See my post from last week for more context on why we built this: https://news.ycombinator.com/item?id=8168792)

>> Instead, we created a custom version of the signing tools which complied with the Authenticode spec (for Windows) while letting us safely modify content for each binary. Our custom tool allows us to create an unverified section of the binary in a way that is compliant with the Authenticode spec. >>

Can you offer some more info on this topic in a follow-up post?

Inside the Authenticode signature, there is an area for unauthenticated attributes (e.g., if you timestamped your executable, the timestamp (PKCS#9) is stored as an unauthenticated attribute, http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-u...). These attributes are not verified by Windows Authenticode when the executable is run. So if you can add a new unauthenticated attribute into the signature, you can make any change we want to that attribute without invalidate the signature.

In order to inject an unauthenticated attribute to the signature, you may want to use osslsigncode for signing (instead of MS signtool).

The UX of this blog post on mobile (HTC One M8, kit Kat) forces a horizontal scroll to read all of the page's content.

update: the non-responsive display was due to rendering of the page in the HN mobile app (by Creative Pragmatics) that I use. Visiting the page in a proper browser proved a better experience.

I typically set my browser to clear cookies every session. Is there any provision for such a scenario? The authentication flow seems to suggest that if the browser was closed and cookies cleared, the user would not be allowed to install Dropbox.

> If any of our conditions isn’t met, we abort auto sign-in and ask the user to log in with an email and password.

In this case, the install succeeds and only auto sign-in fails.

The ultimate fallback always is to revert to letting user sign in manually. Installation success doesn't depend on cookies, so that should be just fine.

I wonder if there are any plans to rewrite the desktop client in C++ (with some Objective-C++ on Mac), presumably using the libdropbox C++ libraries that Dropbox has been developing for the mobile apps, to get the installer size down and leverage more common code across platforms.

Not currently, unfortunately. The complexity of how the Dropbox client works is enough to not pollute libdropbox with at this time. The idea here is correct though - were we to rebuild it at this time, we would look at potentially abstracting a lot things into a libdropbox-like library

I'm surprised you haven't tried harder to optimise the download size ... the blog post says it ships a nearly full Python runtime, but surely you don't actually use it all? The core interpreter is I'd think quite small and Python code should compress very well.

Honestly, I find their mobile offering really disappointing. Several times I've wanted to do things with it and not been able to, like login using only the mobile app and download some pictures I backed up for my wife, etc.. They don't seem to see the mobile app as a real, full app. This connect to desktop thing just makes it even worse. I didn't have my laptop around at the time. We've had other big issues with it involving the iPad version not being able to do things.

"...while letting us safely modify content for each binary. Our custom tool allows us to create an unverified section of the binary in a way that is compliant with the Authenticode spec."

sounds like Condi didn't need much time for Dropbox to build a nice new home for NSA implants.

quite an intriguing attack surface for mobile malware...arbitrary code of Dropbox's choosing when combined with another 0day or two? no thanks.

this makes me glad i dropped dropbox like a bad habit.

What's the use case for drop box on mobile devices (other than tablets)?

I use it as online backup for my photos -- the dropbox app syncs them when I'm on wifi.

Photos and quick viewing of shared documents are common use cases.

I use it with You Need a Budget to sync between my phone and my computers.

Reply on news.ycombinator.com