Live data from Hacker News

The Insecurity Industry

edwardsnowden.substack.com

171–180 of 386 posts

Re: The Insecurity Industry

#171

I find Snowden's take on software engineering to be poorly reasoned and internally inconsistent. The most important fact related to his argument is one he doesn't even bother mentioning, namely that Android is mostly written in a memory safe language (Java). The thing he's asking for already exists and is deployed on most smartphones worldwide, yet all he has to say on the topic is this: "While iPhones are more priva…

Which part of Android is written in java? The kernel? The drivers? The JVM ? I somehow doubt anything significant of the OS itself is written in java :)

Re: The Insecurity Industry

#172

>basically turns the phone in your pocket into an all-powerful tracking device that can be turned on or off, remotely, unbeknownst to you, the pocket’s owner even more so with Android & iOS.

Targeting those is for n00bs. Backdooring the modem firmware is far more useful, and reliable. Not to mention undetectable -- not only is the user unable to recompile or replace this firmware, they can't even get a checksum of it. Qualcomm's modem chips get their own private NAND flash that they can use as they please.

Realistically, how useful is compromising modem firmware if like 98% of communication done through it is encrypted at the AP level? It’s sorta like wiretapping a fiber optic cable—okay, what now?

Re: The Insecurity Industry

#173
> Fixing the hardware, which is to say surgically removing the two or three tiny microphones hidden inside, is only the first step of an arduous process, and yet even after days of these DIY security improvements, my smartphone will remain the most dangerous item I possess.

What's the purpose of these microphones? Do they pose more threat than the standard non-hidden microphone?

Re: The Insecurity Industry

#174
post #171

I find Snowden's take on software engineering to be poorly reasoned and internally inconsistent. The most important fact related to his argument is one he doesn't even bother mentioning, namely that Android is mostly written in a memory safe language (Java). The thing he's asking for already exists and is deployed on most smartphones worldwide, yet all he has to say on the topic is this: "While iPhones are more priva…

Which part of Android is written in java? The kernel? The drivers? The JVM ? I somehow doubt anything significant of the OS itself is written in java :)

Which parts? I'm surprised this isn't well known already. Large parts of Android are written in Java. Amongst other things:

* All the UI libraries, networking APIs code.

* All the system apps and services like the home screen, the keyboard, the system server, the window manager, the telephony subsystem (very important!) and so on.

* Many of the system APIs including services like the alarm manager, dropbox manager, some cryptography services, location services etc.

* The entire developer toolchain: the build system and the IDE.

* All the client logic for Google Play Services, which is a big part of the overall Android API now.

* Large parts of the compatibility test suite.

* The standard libraries for all the above.

Just browse through the code and see for yourself: https://cs.android.com/android/platform/superproject

Most of the Java code is under the frameworks directory. No, not all Android code is written in Java. Lots of devs want to be able to use C++, and for some things its necessary. The point of the upgrade projects I just mentioned is that they are tackling the remaining cases where C++ can outcompete Java for things like media codecs. And the Java world has developed a JVM written in Java, actually several of them, so whilst Google hasn't done it, the tech is actually there. All this exists today, whereas an entire widely adopted consumer OS written fully in Rust is only a pipe dream.

Oh, and as for drivers, Google moved drivers out of the kernel and into user space some time ago (Project Treble):

https://source.android.com/devices/architecture

You can in fact now write drivers in Java. Google recommend you don't, but it's architecturally possible:

https://source.android.com/devices/architecture/hidl-java

Re: The Insecurity Industry

#175

Is Python a safe language? It doesn’t seem to have the sorts of problems other languages do. Why is that?

Absolutely not, unfortunately. One of the architectural issues plaguing even comparatively memory-safe languages is the fact that there is a global scope that's accessible from anywhere. In some Python versions even numbers or truth values could be redefined. [0]

This makes it impossible to sandbox functions or imported modules, because they can communicate arbitrarily. But communication/access security is not the only problem. Resource security is something I haven't seen any significant language (besides Java perhaps) try to approach - being able to limit the memory and cpu usage of a (part of a) program. Modern languages should make it possible to do both with just a few lines of code.

I recommend reading about Capability Security[1], the E language[2] and the Principle of least Authority (POLA) [3]

[0] https://hforsten.com/redefining-the-number-2-in-python.html

[1] http://www.cap-lore.com/CapTheory/

https://en.m.wikipedia.org/wiki/Capability-based_security

[2] http://www.erights.org/

[3] https://medium.com/agoric/pola-would-have-prevented-the-even...

These originated in the mainframe era, in a connected world before the internet, at the inception of the first multi-user systems: https://github.com/void4/notes/issues/41

Re: The Insecurity Industry

#176

I find Snowden's take on software engineering to be poorly reasoned and internally inconsistent. The most important fact related to his argument is one he doesn't even bother mentioning, namely that Android is mostly written in a memory safe language (Java). The thing he's asking for already exists and is deployed on most smartphones worldwide, yet all he has to say on the topic is this: "While iPhones are more priva…

If you really cared about the topic, you'd see beyond your favorite language getting rekt, because let's be honest - it's shit because of people who are using it.

And that's why we can't have nice things - shortsighted manchildren like you are making it impossible.

Re: The Insecurity Industry

#177
Everyone in these comments mentions C and C++ as a single word, which frankly has nothing to do with reality. C++ is a FAR safer language than C, if you wish to use it properly (which many don't). I write C++ full time at work and I also use it a lot in my free time and I rarely if ever have out of bounds accesses, use after free or any of these bullshit errors. If you use modern C++ and AdressSanitizer and don't do anything too "fancy" then it's very hard to get those types of bugs. I firmly associate them with C and C alone. These time are over for modern C++. The people commenting here clearly have no idea what modern C++ even looks like.

Re: The Insecurity Industry

#178

Earlier quoted context omitted.

As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes. Yes C/C++ have more footguns than Java but there's no "hard line" in the safety differences and there are real and important things that need doing that it's not always clear can be reasonably done in another language. If you haven't, I'd encou…

The line is far less blurry than you suggest. The stats from the article say 70% of vulnerabilities come from [insert list of a few memory-wrangling mistakes here]. I'd consider any language that enables the top 70% of vulnerabilities to happen to be unsafe. Maybe a safety ranking is in order? How many CVEs from [year], weighed by severity, are impossible to happen in [language]. Obviously this idea has serious probl…

An statistical approach like that has the flaw any the most used language would always appear to be at the top of the "most unsafe".

Instead, people should be schooled to write better code. Thats it. Don't let some random new employee with no certifications write safety-critical code. Don't hire people who are under qualified. Its really that easy.

I have no idea, honestly, how you would introduce a use-after-free bug with C++'s smart pointers. Its the lack of schooling, the lack of certification, and the lack of a safety-focused selection of applicants, not a language that you can write bad code in if you ignore all warnings and advice.

Even rust has unsafe{}, but I dont see anyone complain when thats used to introduce safety issues, because "youre not supposed to do that, even though technically you could".

You can have all the safety mechanisms in a language, but you need control, too, and anyone who is completely unqualified will use that to break something.

Re: The Insecurity Industry

#179
post #177

Everyone in these comments mentions C and C++ as a single word, which frankly has nothing to do with reality. C++ is a FAR safer language than C, if you wish to use it properly (which many don't). I write C++ full time at work and I also use it a lot in my free time and I rarely if ever have out of bounds accesses, use after free or any of these bullshit errors. If you use modern C++ and AdressSanitizer and don't do…

As much as like C and dislike C++ you are right.

Re: The Insecurity Industry

#180
post #177

Everyone in these comments mentions C and C++ as a single word, which frankly has nothing to do with reality. C++ is a FAR safer language than C, if you wish to use it properly (which many don't). I write C++ full time at work and I also use it a lot in my free time and I rarely if ever have out of bounds accesses, use after free or any of these bullshit errors. If you use modern C++ and AdressSanitizer and don't do…

The problem for modern C++ is that few (or zero?) code bases contain exclusively "modern C++" when you include all transitive dependencies. You end up using a huge amount of C and "legacy C++" just by virtue of reusing code.
Post reply on HN