Hacker News Reader

Comment by LoSboccacc | Hacker News Reader

"man in the middle can do nasty thing, here is a castle of vulnerabilities we built on top of already having pwnd the communication channel"

related http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235... "It rather involved being on the other side of this airtight hatchway"

View on HN

I can't for the life of me find it, but there was a paper a few years ago about evading App Store policies by purposely introducing vulnerabilities in your app. The idea being that e.g. you have a buffer overflow and the app makes a specific network request that exploits it, resulting in code execution free from Apple's policies. So that ONT post is a bit short-sighted in thinking bugs that don't result in privilege escalation aren't "security holes."

Coincidentially I heard about this at a recent talk - is it this:

http://www.imore.com/jekyll-apps-how-they-attack-ios-securit...

Jekyll apps in App store

That's it, thanks!

For anyone wanting to read the paper itself, the link the imore.com article is broken. Use this one instead: http://www.usenix.org/system/files/conference/usenixsecurity...

Evading Apple's policies isn't a security thing, though. What keeps the system secure from malicious activity by your app is the sandbox that your app is executed in. Putting in exploits that you then use yourself is just a weird way of obfuscating your code to bypassing non-security restrictions, and it's one that involves way more effort than is necessary. Much easier and just as effective to embed a small interpreter and make a HTTP request back to your server on launch to see if it has any code for you to run.

My new favorite: "I have discovered a critical security vulnerability in Windows which I intend to present at the XYZ conference. It allows any user with administrator privileges to perform operation Q, something that should be available only to SYSTEM."

http://blogs.msdn.com/b/oldnewthing/archive/2015/09/23/10643...

This was my first reaction too, but I took the time to read through most of the paper. The end result is that someone visiting "unsecure.com" means they can no longer trust Gmail's chat interface. That's pretty obviously a vulnerability.

True, it's more of an issue with web apps themselves and not using HSTS.

Perhaps the real problem is the terrible clickbait title. The actual authors had much better sense and taste: "Cookies Lack Integrity: Real-World Implications". Perhaps HN mods could change it.

Ok, we changed the title and the URL from http://www.kb.cert.org/vuls/id/804060 to the original source which it points to.

I might be nitpicking, but I disagree with Raymond Chen here.

Regarding his example, IMO, the process of saving a file has a platonic security abstraction, it is a very limited computation engine. When one is able to escape this abstraction, it is a security concern.

The distinction between a security bug and non security bug is very subtle.

An example how this violation may happen in real life. Assume a filesystem that may contain long filenames, an attacker may control it and cause remote execution. Another scenario may be a site that tells you to see an easter egg in notepad by fire up notepad and save a file named <payload>, which will do some trick and will also run arbitrary code on your machine.

Right. What Raymond is trying to say is that if the attacker is someone else (in your case, the attacker is the person getting the victim to use a specific long filename), then it's escalation and hence an issue. Otherwise his post would mean that even opening a bad Word doc isn't a security hole.

Thus, if you are trying to show Windows is broken, and YOU are the attacker making up this long filename to inject code into your own process, then a buffer overflow isn't a vuln.

Still as I mentioned on Raymond's original post, this doesn't quite work as Windows has things like Software Restriction Policy (and AppLocker). With that in mind, it is a vuln in the app if an app lets you inject code since you couldn't do so otherwise.

that's not a fair comparison since https is supposed to prevent mitm.

it is fair because the paper injection works by either pwning a subdomain or be the MTM, hence it involves already being on the other side of the airtight hatchway

Being the MITM isn't hard ("free public wifi"). That's one of the reasons we have HTTPS. If being MITM can get you around HTTPS then... that's not good.

The MITM is not "getting around HTTPS". It's exploiting vulnerabilities in web apps. Hence the paper's name of "Cookies Lack Integrity: Real-World Implications" instead of the nonsense "bypass HTTPS" title used here.

I'm on a cafe's wifi all day long. The channel cannot be trusted.

Reply on news.ycombinator.com