6 ms·
"Protection from zero-days" -- how can you make a claim like this?
by mmanfrin 11y ago
"Protection from zero-days" -- how can you make a claim like this?
- neerdowell 11y agoIf a zero-day is found in standard Android (ala Stagefright) it's possible it won't be exploitable on Copperhead because of the hardened malloc, overflow protections, bounds sanitizing etc.
- rinon 11y agoI'm not affiliated with Copperhead at all, but I am familiar with the sorts of techniques they are using. Exploit mitigations, such as Address Space Layout Randomization, Control-Flow Integrity, Fine-grained Randomization, etc. provide a layer of hardening to make exploitation of a source code vulnerability harder, or even not possible on the protected device. The bug (zero-day) still exists, it's just not as exploitable to do bad stuff.
- vox_mollis 11y agoASLR is already a part of pretty much every current operating system ( save FreeBSD-RELEASE )
- rinon 11y agoIndeed, I was trying to give well-known examples. Some of the more interesting, not widely-deployed PaX mitigations are more accurate here.
- neerdowell 11y agoNot all ASLR implementations are equal, eg. PaX's ASLR vs standard Linux KASLR.
- droopybuns 11y agoI've heard rumors that the new ASLR in Android N is actually worse than the current implementation. I don't have anything online to link to, unfortunately.
- mtgx 11y agoOr Android's almost useless 32-bit ASLR (even on 64-bit platforms) for that matter: https://googleprojectzero.blogspot.com/2015/09/stagefrightened.html https://googleprojectzero.blogspot.com/2015/09/stagefrighten... https://copperhead.co/blog/2015/05/11/aslr-android-zygote https://copperhead.co/blog/2015/05/11/aslr-android-zygote
- Animats 11y agoASLR is a band-aid. If you need it, your system is already insecure. It's just that the attacker may need to crash your system a few times before they get in.
- hackcasual 11y ago64 bit ASLR is not a bandaid. There are definitely ASLR approaches that don't have enough entropy, but that doesn't mean ASLR as a whole is unworkable.
- viraptor 11y agoAll systems need it. All systems are already insecure. All desktops systems already implement it. This has been the situation for years now.
- nickpsecurity 11y agoNo, they need tech that either contains the attack in its own partition or prevents it entirely by language/compiler-level action on the target. Both exist in academia and commercial sector with varying capabilities, prices, maturity levels, and so on. Most such things are rejected in favor of band-aids like ASLR. And the systems continue to get hacked through the very holes covered in bandaids. As he said, if you're using a bandaid, you're covering up something inherently broken.
- viraptor 11y agoThat's not a practical solution. Sure - you could write super-secure (Ada-style?) code in a verified environment (?), running on verified kernel (SL4?), on secure hardware (got any ideas how to solve rowhammer?). Realistically though - nobody does that (in a product which we can buy). Producing any application in that kind of environment would be too expensive and not possible for most companies. We don't even have secure hardware available. Academia will experiment with that. Some industries will care enough to apply it. But in a mass-produced software/hardware? Realistically my choice for productive desktop is OSX/Win/Lin. We can talk about cool, perfect solutions for a very long time. In the meantime I'm making sure my apps are running with ASLR. I hope you're not actually advising people not to use it, just because there's some ideal solution maybe possible on the horizon, that doesn't run any apps they need?
- mtgx 11y agoThey talk a bit about them in these posts: https://copperhead.co/blog/2015/06/11/android-pax https://copperhead.co/blog/2015/06/11/android-pax https://copperhead.co/blog/2015/07/27/hardening-bionic https://copperhead.co/blog/2015/07/27/hardening-bionic https://copperhead.co/blog/2015/05/11/aslr-android-zygote https://copperhead.co/blog/2015/05/11/aslr-android-zygote
- strcat 11y agohttps://copperhead.co/android/docs/technical_overview https://copperhead.co/android/docs/technical_overview covers much more and is mostly up-to-date.
- bache 11y agoIt does seem like a ridiculous claim
- markcerqueira 11y agoIt's how you interpret "protection." They didn't say you'd be "protected from all" zero-days.
- msh 11y agoThey complete text is: Protection from zeroDays Prevents many vulnerabilities and makes exploits harder So they don't claim to provide immunity from zero days, but
- throw_away_dead 11y agomarkcerqueira, your account is dead and has been dead for quite a while now. Since I'm on the subject, dang, you are a low-down piece of shit scumbag. This person markcerqueira has posted several times since you killed his account without the slightest clue he is just typing into the wind. If you are going to fuck somebody's account off, at least be a fucking man and tell them about it.
- stcredzero 11y agoFrom what little I know about Android vulnerabilities, most 0-days on Android have to do with interfacing directly with C/C++ and optimizations.
- brianmwaters_hn 11y ago"Zero-day protection" is marketing-speak for what security engineers call "exploit mitigations." Of course they don't prevent exploits; they mitigate them. Pretty typical that the marketing term is an exaggeration of the more accurate engineering one.
- strcat 11y agoExploitation can certainly be outright prevented. For example, automatic integer overflow checking reduces any integer overflow vulnerabilities to at most a denial of service attack (clean abort). _FORTIFY_SOURCE (including the more dynamic implementation in CopperheadOS) does the same thing for a large subset of buffer overflows, as does -fsanitize=bounds which is globally enabled.
- strcat 11y agoSee https://copperhead.co/android/docs/technical_overview https://copperhead.co/android/docs/technical_overview.