4 ms·

"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://blo

"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/592350.aspx http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235... "It rather involved being on the other side of this airtight hatchway"

Chlorus 11y ago
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/10643223.aspx http://blogs.msdn.com/b/oldnewthing/archive/2015/09/23/10643...
adamnemecek 11y ago
that's not a fair comparison since https is supposed to prevent mitm.
- LoSboccacc 11y ago
  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
  - HeyImAlex 11y ago
    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.
    - MichaelGG 11y ago
      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.
jacobwcarlson 11y ago
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."
- mbubb 11y ago
  Coincidentially I heard about this at a recent talk - is it this: http://www.imore.com/jekyll-apps-how-they-attack-ios-security-and-what-you-need-know-about-them http://www.imore.com/jekyll-apps-how-they-attack-ios-securit... Jekyll apps in App store
  - jacobwcarlson 11y ago
    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/usenixsecurity13/sec13-paper_wang-updated-8-23-13.pdf http://www.usenix.org/system/files/conference/usenixsecurity...
- mikeash 11y ago
  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.
ddandd 11y ago
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.
- MichaelGG 11y ago
  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.
3pt14159 11y ago
I'm on a cafe's wifi all day long. The channel cannot be trusted.
MichaelGG 11y ago
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.
- dang 11y ago
  Ok, we changed the title and the URL from http://www.kb.cert.org/vuls/id/804060 http://www.kb.cert.org/vuls/id/804060 to the original source which it points to.

Chlorus 11y ago

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/10643223.aspx http://blogs.msdn.com/b/oldnewthing/archive/2015/09/23/10643...

adamnemecek 11y ago

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

LoSboccacc 11y ago
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
- HeyImAlex 11y ago
  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.
  - MichaelGG 11y ago
    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.

jacobwcarlson 11y ago

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."

mbubb 11y ago
Coincidentially I heard about this at a recent talk - is it this: http://www.imore.com/jekyll-apps-how-they-attack-ios-security-and-what-you-need-know-about-them http://www.imore.com/jekyll-apps-how-they-attack-ios-securit... Jekyll apps in App store
- jacobwcarlson 11y ago
  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/usenixsecurity13/sec13-paper_wang-updated-8-23-13.pdf http://www.usenix.org/system/files/conference/usenixsecurity...
mikeash 11y ago
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.

ddandd 11y ago

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.

MichaelGG 11y ago
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.

3pt14159 11y ago

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

MichaelGG 11y ago

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.

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