> Next time I won't post in a rush during work hours.
I'd suggest taking the same approach with your "secure, end-to-end encrypted communications" app you keep mentioning here[0]
A one-way sha256 hash of a message using a password that has to be 8 characters long[1] and can't accept special characters[2] is not a secure communications app
It is trivial to find the plaintext in these situations.
Your Chrome extension has a very elementary RCI bug in it[3], which because of your extensions broad permissions[4] profile means anyone with your extension installed can have any code executed by visiting any page.
To release (excuse me) crap like this on one hand while FUD'ing Google's security practices on HN on the other requires a level of hubris that I don't think i've ever previously encountered.
Could you explain how [3] is an RCI bug? getNum() returns either 'false' or 'n' with the length of gibberText (ie. n20, n35, etc). I can't imagine any content where .length() would return harmful code; though I'm not well versed in JS.
Believe it or not, I would love to get Nik as a consultant. I fear my 'hubris' (I won't deny it, this idea is extraordinarily ambitious and I have to be arrogant to even conceive of it) will have pissed him off irrevocably.
That aside, I don't really follow his point on the login PW. I understand 8 char alphanum pw is pretty low entropy... but that isn't used for encryption. And the login attempt rate is pretty strictly rate limited.
And yes, I am getting professionals - not me - to do the heavy lifting. I wrote the proof of concept. I am in no way surprised to find it has issues - I am aware of a few others myself.
It isn't the login password but the message password - although using sha256 for a login password isn't great either
if you're doing
aes(plaintext, sha2(password)) = cyphertext
given cyphertext I can get to plaintext with sha2(8-char dictionary)
well designed systems will generate a truly random key there, exchanged using public-key. if you're going to use a password, you need a key-derivation algorithm
this is all bunk tho since the big vulnerability here is that you're delivering the encryption routines via javascript in a global browser space
Nm, I understand your point, and yes, no contest. The extension is being broken up and will communicate with the environment on the tab with sent messages, rather than just injecting the whole content script. I hear your point loud and clear.
I'd probably take the site down, or mark it clearly as being a hobby project.
As for Chrome - that team has some of the smartest infosec and cryptography people in the world working on and contributing to the project. If you want some insight into how some of the security design principals and tradeoffs were rationalized, i'd start with the project wiki:
Yep. Same. And I would probably have posted a longer and less confrontational explanation of why you're (mostly) wrong if I weren't tired after a long day of work. ;)
The whole "why not encrypt local resources" thing is an odd red herring that a lot of (even fairly experienced) people trip over. There was a massive public furor over Chrome's chrome://settings/passwords (i.e. lack of a master password) design choice a couple of years ago that was a specific such case in point.
> Here is my take as an information lawyer and (slightly-higher than script-kiddy-level) web developer
as a "(slightly-higher than script-kiddy-level) web developer" I'm going to guess that he doesn't actually know very much about AOSP, the Linux kernel, or indeed GNU/Linux security in general. So his emphatic statement "Compare the security of Android - which we now know to be 'owned' by the US Government" is pretty much worthless as he's very clearly speculating about things that he doesn't understand.
> I'm going to guess that he doesn't actually know very much about AOSP, the Linux kernel, or indeed GNU/Linux security in general.
I know a fair amount for a 'layperson', which you can (probably rightly) argue means I am unqualified for comment in these circles, and you are right that I am including too much speculation. I absolutely, inarguably overstepped. My bad.
However, with regard to Android being owned - this article is literally about the CIA tools that are used to compromise Android. The trove has been released. It is incontrovertible at this point: https://www.washingtonpost.com/world/national-security/wikil...
The issue is to what extent other fundamental assumptions are now called into question. Is it only android, or is Chrome now suspect as well? What protocols are compromised?
I suspect we will find out more in the coming days, and I should have been more circumspect in my own post. It was unbecoming.
You should be careful about making bold proclamations about the supposed insecurity of Linux or AOSP. Especially under the guise of tech-savvy lawyer. And just because you made a browser extension that doesn't trust Chrome's security model doesn't mean you're also qualified to confirm the complete and utter "owning" of the Linux kernel on ~5 year old Android devices.
If this is not the case, then what is your conclusion? Because the claim that is being made far and wide, right now, is that android, ios and samsung smart TVs appear to be fundamentally compromised.
As far as I can tell, my question ("which line of code is broken?") is also not answered either in the NYT piece or the wikileaks release. If I'm wrong, do you have a link?
I spent a fair amount of time reading up on the wikileaks last night. While the released info does appear to not be beyond KitKat, the array of listed hacks is staggering. Have you had a chance to look? I understand that there are very fine levels of distinction between these types of hacks, but it seems to me that there were multiple root compromises.
Was going to email you but I couldn't find a way of getting your contact information without enabling google JS (something you might want to consider as a privacy advocate)
The background video on gibber is awful, makes it very hard to read the page. I've just opened it in another browser with all the JS on and again your page totally doesn't work with the google ajax switched on. Worth fixing.
>Compare the security of Android - which we now know to be 'owned' by the US Government - with the security of iOS, which was the subject of a public and gruesome lawsuit about a year ago because the Fed could not hack iOS.
So your comparing the current security of the iPhone with old CIA Android and Chrome exploits from circa 2011-2013?
> Please be aware that the Chrome browser does not offer a secure local storage protocol for its developers ... Compare this to Safari, which offers secure local storage at OS level security
But this is just as secure as full disk encryption of the device right?
Running in user space is not enough. It would need root. It is also hard to keep root, when you have dm-verity and selinux in enforcing mode.
Android applications are also sandboxed from each other. You would have hard time getting from one app to another's files, unless the original app published them - or you've got root.
The browser runs in user space. Desktop OSes don't offer any sort of partitioning here. So there's very little reason to have any app-level encryption on a desktop OS.
Eh, they couldn't hack (1) the device in standby/locked with keys flushed and (2) the encrypted physical data on the flash. But that is a much more difficult proposition.
Just hacking the device while it is being used is what every iOS jailbreak does. And there seem to be quite a number of them.
Not sure why you mention "secure local storage"; none of that local storage is secure if the device is compromised! That can then be bypassed in the same way that you bypass WhatsApp or manipulate any other app on the device.
I would like your take on a more specific question: Do you think that Google applications (GMail, Search, Translate, Maps, etc) themselves can get access to the necessary kernel subroutines to catch information which is intended for encryption? Or would running a custom rom (ie. cyanogenmod) while still using Google applications suffice to mitigate these attacks?
If you are running something based off of AOSP, you're running code that was touched by Google employees. Is your fear that Google is installing backdoors to help the CIA? If so, why are you afraid of that?
> you're running code that was touched by Google employees
Doesn't matter who touches code when that code is publicly visible and available to the scrutiny of everyone. AOSP can be checked out and audited independently, just like any open source project.
Sure, I guess. As I noted elsewhere in this thread, in general your risk is that the cost of exploitation is low (e.g. Android 4.x) or your value of exploitation is high (e.g. San Bernardino shooter).
Open vs closed source is a distinction I don't see a lot of folks in the security community take seriously, and for good reason: it's a response to a very specific threat model, where your concern is not primarily accidental 0days but intentional backdoors.
I would posit that the cost of a backdoor is probably higher than the cost of an 0day: the reputational risk to Google or Apple if they were discovered to have planted one is worth potentially billions of dollars in sales, so they will spend a lot of money fighting any such court order (and, as far as we know, such an order has never been successfully made).
The counterargument here is that if the government did win such an order, the backdoor is the gift that keeps on giving, whereas 0days eventually get patched and fixed.
But that's a long digression. For most users, this is simply the wrong threat model.
Right, so in the scenario I mentioned, an update to a Google application would give this application more access to the kernel (through some backdoor) and enable it to intercept the communication of other apps. I'm asking whether this is possible or not - assuming the kernel itself cannot be modified. If that's the case then parts of the android kernel or the way android handles access to microphones, etc. might need to be hardened in the future.
Google Apps are typically installed as system apps. Play Store is obvious, since it needs to be able to install/update applications without prompting. The need for other apps (e.g. Gmail) to need system-level permissions is less obvious, but most of them fail to run if you just sideload it without the permissions.
Huh? What permissions are you referring to that the Gmail app has?
Also, if I remember right (and I'm not an Android expert, so grain of salt here), Android OS itself enforces sandboxing based on app signing keys; even the Play app can't overwrite the Signal binary without a binary signed by the same key (though conceivably it could install some other fake-Signal app that looks just like Signal and has a similar icon--but that app would not have access to your private key!).
Yes, that is my concern. You mention system applications - I believe this excludes any application which can be installed (with an app store or apk)? What is a local EOP? I couldn't find any info on this abbreviation. I used Google as an example.
EOP = Elevation Of Privilege. e.g. a local->root exploit.
To expand, this would be some vulnerability which allows a non-privileged local app (like Gmail) to execute code at a higher security level.
The focus on Google apps specifically here is misleading. In the Android (and iOS) security model, apps are sandboxed, and cannot generally inject code into other apps (in contrast to most desktop OSes, where all processes running as "you" can sort of do what they want to each other).
The threats that apply on Android or iOS are, roughly speaking:
1. You grant an app more permission than it should have (e.g. microphone or keyboard input)
2. Local EOP plus installing a malicious nonprivileged app (or a remote code execution vuln) such that someone can get root on the device and inject code into Signal (or whatever)
3. A backdoor in the OS or app you are using
Android and iOS both have vulnerabilities in the wild. Older Androids are riddled with them, and the Android ecosystem is shit for getting updates out. If you're not using a Nexus or Pixel or a device from a reputable OEM (supposedly Samsung takes patches seriously, but I don't pay attention to this), you're probably easily exploited.
That's all the news that's here, AFAICT. The focus on encrypted messaging apps is on the one hand silly and on the othe rprobably necessary. Everyone in the security world knows that the easiest way to beat end-to-end encryption is to compromise the endpoint. But everyone in the wider world thinks that if they use Telegram they're secure, even if they're using an unpatched Samsung from 2011.
I'd suggest taking the same approach with your "secure, end-to-end encrypted communications" app you keep mentioning here[0]
A one-way sha256 hash of a message using a password that has to be 8 characters long[1] and can't accept special characters[2] is not a secure communications app
It is trivial to find the plaintext in these situations.
Your Chrome extension has a very elementary RCI bug in it[3], which because of your extensions broad permissions[4] profile means anyone with your extension installed can have any code executed by visiting any page.
To release (excuse me) crap like this on one hand while FUD'ing Google's security practices on HN on the other requires a level of hubris that I don't think i've ever previously encountered.
[0] https://www.gibberit.com/
[1] http://i.imgur.com/CsgOkZ2.png
[2] http://i.imgur.com/uZg0E4l.png
[3] http://i.imgur.com/eq19mET.png
[4] http://i.imgur.com/lOsibBP.png