[rajathagasthya]

> This attack exploited the complex interaction of multiple issues in our code. It stemmed from a change we made to our video uploading feature in July 2017, which impacted “View As.”

Obviously, Facebook is an extremely complicated system. But I find it hard to believe a video uploading feature would impact 'View As'.

[throwawaymath]

It's very easy for me to believe. "View As" is an authorization and authentication sensitive, limited user impersonation feature. Video uploading interacts with, and complicates, authorization in an application with fine grained privacy and permission models.

It's intuitively straightforward that modifying code for uploading videos could (read: not should) have authorization and authentication ramifications. One of those ramifications could then result in a vulnerability chain compromising user impersonation functionality.

I have seen far, far more incredulous head scratchers in penetration tests and code reviews. The interaction boundaries of, or middleware between, two seemingly unrelated systems is generally a good start to look for a security vulnerability.

[rajathagasthya]

> It's intuitively straightforward that modifying code for uploading videos could (read: not should) have authorization and authentication ramifications.

I get this part. But why would it affect only videos and not other entities (photos, status etc.)? I would think creating (or uploading) any of the entities have the same authorization and authentication ramifications. What could be different for videos? Unless the privacy models are so fine grained that you can have different privacy settings for different entities (haven't used Facebook in years, so I don't really know). Your explanation makes sense, I'm just looking for a concrete example.

[munchbunny]

As someone who works specifically on user authentication stuff...

The problem is often that there are multiple sources of truth for who the user is. And if you have an impersonation feature, you by definition have two sources of truth: who the user actually is, and who the user is impersonating. It would just be a matter of a single mistake of using the wrong one.

Considering that "view as" requires your page view to render every control as the impersonated user but only when it comes to your profile, but renders all controls outside of your profile as the original user, I could see any engineering team dealing with some very carefully drawn and potentially confusing boundary cases.

Edit: just to elaborate, it's not just obvious impersonation contexts where this gets interesting. For example, linking your Humble Bundle account to your Steam account, or on Netflix which user you are vs. which email address is being billed. Many apps have a function to share some document using a one-time expiring token. If you're also logged in, then do you read permissions from the shared token or from your account? If you mix them, do you make sure anything that writes to this shared view can't touch your account itself on accident? We don't think about it much but I think you can see how these subtle distinctions are important when you are thinking about access control, and that makes it a breeding ground for subtle mistakes.

[mkagenius]

They said they introduced bug in video uploading part in 2017. All were Ok till then.

[xianb]

sounded like the video stuff was added after view as was added so it probably didn't go through the same level of scrutiny

[mic47]

Mayve it has some complicated privacy rules?

[rajathagasthya]

Possible. Some more technical details would be nice, but I doubt Facebook releases the post-mortem to the public.

[nerflad]

If I recall correctly this is not the first FB vuln relating to View As. I searched and can't find it, but I seem to remember there being a bug around 2009 where you could basically take over a friends' account by viewing your profile as them.