Live data from Hacker News

Remote Code Execution on a Facebook server

blog.scrt.ch

21–30 of 207 posts

Re: Remote Code Execution on a Facebook server

#21
post #5

In contrast, I submitted a bad vulnerability in Facebook’s password reset feature yesterday that lets attacker’s send password reset PIN numbers to email addresses the user doesn’t necessarily control. The security team said to works as designed so they’re not going to fix it. Basically if someone requests a password reset on your account then the PIN number gets sent to all email addresses associated with your accou…

I tend to agree w/ the FB security team here. Don't list email addresses owned by an adversary in your account. :-/

> Don't list email addresses owned by an adversary in your account.

I mean if you're delegating your email address, your staff aren't adversaries. But they shouldn't be able to, say, drain all your retirement accounts either.

Just because I want people who search for alex.krupp@gmail.com to be able to find my Facebook account doesn't mean I want password reset requests sent there. It wouldn't be at all unreasonable to send them there if that was explained in the UI, but just immediately sending a password reset pin to a non-primary email address without any warning is crazy. At least wait a few days if the user doesn't take any action after it's sent to their primary address.

Re: Remote Code Execution on a Facebook server

#22
post #14
post #5

In contrast, I submitted a bad vulnerability in Facebook’s password reset feature yesterday that lets attacker’s send password reset PIN numbers to email addresses the user doesn’t necessarily control. The security team said to works as designed so they’re not going to fix it. Basically if someone requests a password reset on your account then the PIN number gets sent to all email addresses associated with your accou…

Using a delegated email address to sign up for things sounds like the vulnerability then, not Facebook's handling of it.

That scenario obviously wouldn't be Facebook's fault, because any email address you sign up with is always going to be your primary email address unless you change it later. What I'm talking about is signing up with a non-delegated email address, and then adding a secondary email address for the purpose of either displaying publicly on my profile or so that my friends can find me via email in search.

In other words, cases where I had no intention of ever allowing a password reset request to be sent there, knew fully well that it wouldn't be safe, but did so anyway because Facebook provided zero indication that they would do this and it's not at all intuitive that they would.

Re: Remote Code Execution on a Facebook server

#23
Other than fixing the Django source code , is there any OS level mitigation techniques that can detect and prevent such security vulnerabilities?

I am thinking something like selinux, docker or chroot - a bit like internal firewall for Django (or any other webapp).

Any suggestions on the links to latest best practices?

Re: Remote Code Execution on a Facebook server

#24
post #23

Other than fixing the Django source code , is there any OS level mitigation techniques that can detect and prevent such security vulnerabilities? I am thinking something like selinux, docker or chroot - a bit like internal firewall for Django (or any other webapp). Any suggestions on the links to latest best practices?

Depends on your threat model. For all we know chroot, docker, and SELinux could have been in active usage on this machine.

But Facebook may view a compromise on their edge network and potentially one of their trusted servers as serious even if actual damage on that server itself is limited.

Re: Remote Code Execution on a Facebook server

#25
post #23

Other than fixing the Django source code , is there any OS level mitigation techniques that can detect and prevent such security vulnerabilities? I am thinking something like selinux, docker or chroot - a bit like internal firewall for Django (or any other webapp). Any suggestions on the links to latest best practices?

To be clear, this isn't an issue with the Django source, as much it was a miss configured server - having debug mode on enabled the stack trace to be leaked which yielded the secret key. Debug mode shouldn't be used in production, and django probably shouldn't be responsible for snipping every possible value out of debug traces.

Re: Remote Code Execution on a Facebook server

#29

This is a great concrete example why you should never run debug mode on a public server. Django can only do so much for redacting private info. This is also a great example of how insecure pickle is!

I know this is going to get some jeering, but that's one nice thing about .Net's machine.config , you designate the machine itself as a non-development environment and tracing, debug output, and so on are disabled for all .Net/ASP.Net applications.

That might not work for all edge cases, but broadly there's a lot of machines which are only for non-development/production code, and a system-wide setting makes you a lot safer.

Post reply on HN