zlacker

>>colone+(OP)
> 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'.

>>rajath+92
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.

>>throwa+r3
> 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.

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