Archive

Archive for October, 2018

Linux new Code of Conduct

20/10/2018 Leave a comment

If you have been following technology news, specifically related to free software or open source, even more specifically related to Linux, you probably already know 2 things:

  1. Linus Torvalds went on vacation to “improve his people skills”
  2. Linux Kernel got a sudden and surprising new “Code of Conduct”

Since I am not a kernel developer or an insider of any kind, I have no new information on these issues.

The purpose of this post is to arrange for me and anyone interested, the facts about this situation, in chronological order.

Also, there is a very good Youtube video that analyzes in depth the new CoC but unfortunately it is “unlisted” so will not show in search results.

I wanted to have another place on the web that links to it.

If you want to understand why people complain about this particular CoC, you must watch this video!

No – it is not because developers like being rude and want to keep doing it!

The facts so far:

  1. On September 15, 2018 Greg Kroah-Hartman made a commit to the kernel Git repository replacing the existing “Code of Conflict” with a new “Code of Conduct” taken from this site.All but one kernel maintainers signed off on this commit.
    The one who refused was promptly accused of being a “rape apologist” for his refusal.

    The thing to be concerned about here is the “post meritocracy” manifesto published by the same people who produced the CoC.
    This manifesto goes against the guiding principle behind Linux and most other free software projects: people are judged only by the quality of their work, and nothing else!

  2. The next day, September 16, 2018 Linus Torvalds posted to the Kernel mailing list that he is “going to take time off and get some assistance on how to understand people’s emotions and respond appropriately.”Linus did not state that this is a permanent retirement from kernel development.
    But, he also did not specify when he will be back.
  3. On the same day, Coraline Ada Ehmke, the main author of the CoC twitted the following inflammatory post:

    I can’t wait for the mass exodus from Linux now that it’s been infiltrated by SJWs. Hahahah

    For many this confirmed a malicious intent from the creators of the CoC suspected due to the anti-meritocracy manifesto.

  4. On the next day, September 17, 2018 Coraline confirmed that the CoC was a political document.It should be noted that Coraline has never contributed a single line of code to the Linux kernel.
  5. On September 19, 2018 The New Yorker published a character assassination piece on Linus Torvalds.Many on the net speculated that Linus “chose” to take his time off because the New Yorker contacted him before publishing the article, and this was his attempt to mitigate what was published.
  6. On September 20, 2018 an anonymous user unconditionedwitness posted to the kernel mailing list a claim that there is legal possibility for any developer harmed by the new CoC to demand removal of all their code from the kernel.
  7. On September 23, 2018 Eric S. Raymond posted to the LKML “On holy wars, and a plea for peace” where he stated “this threat has teeth”.
    He claims to have researched the issue and thinks unconditionedwitness may be correct.Unfortunately, Eric is not a lawyer.
  8. On September 26, 2018, ZDNet published an article, attempting to present legal opinion on the possibility of removing  code under GPL v2 from the kernel.Unfortunately, they did not interview any lawyers regarding current situation, just quoted old statements.
    Still, it seems that the possibility of code being removed from the kernel is legally dubious at best.
  9. On October 7, 2018 Phoronix reported that some prominent kernel developers were submitting patches to the CoC in an attempt to mitigate the harm it will cause and make it more usable.Unfortunately, these patches do not address all the problems (see the analysis video), and it is not yet known if they will be accepted.
  10. On October 15, 2018 Phoronix again reported that as of Release Candidate 8 for the upcoming 4.19 kernel no changes to the CoC were accepted.
    So basically, previously mentioned patches were thrown out.There is however another attempt, this time by developer from RedHat to submit more patches trying to fix the CoC.
  11. On October 20, 2018 (Latest news as of the time of this writing), Phoronix reported that though all previous patches were rejected, Greg Kroah-Hartman himself submitted a patch and a new “interpretation” document for the CoC.It is interesting to note, that the interpretation document is longer that the CoC it self, which brings up the question: how bad does a document need to be for it to require such a long interpretation guideline?

    Can you imagine a comment that is longer then the function it documents?
    Would you accept such code?

    Also note, that these changes were discussed privately, and only a very short time before 4.19 release was given to the developer community at large to consider them.

Summary:

It is clear from these events that there is an attack on the Linux kernel project.
Linus Torvalds, the creator of the project was driven out by using prime time media and political pressure, and at the same time a highly controversial at best, and plain destructive a worst, binding document was forced upon the community with no warning and no discussion.

I do not believe anything like this has happened before in the lifetime of the kernel project.

It should be noted however, that as of the time this post was written no other developer besides Linus have been driven off the project or decided to leave of their one free will.
No one is trying to pull code out yet.

 

Analysis of the CoC:

Some month before the CoC hit Linux kernel, Paul M. Jones, a PHP developer, gave a presentation detailing all the problems with the CoC.

You can find it here.

It is an hour long, and the video and audio quality is not the best, but the content is excellent. If you are wondering what is so bad about the CoC that people like me call it and “attack”, you must watch this video.

You should also read this post and this one.

I was going to add my own analysis here, but this post turned out longer than I expected, so I will write up my own dissection of the CoC in a separate post.

Most of it is covered in the video anyway, please watch it!

Categories: Rants Tags: , ,

How not to protect your app

20/10/2018 Leave a comment

So, I went to Droidcon this week.

And to be honest, it disappointed me almost in every parameter: from content to catering.

I don’t go to many conventions, but compared to August penguin that costs about one tenth for a ticket, Droidcon was surprisingly low quality.

The agenda had not one but two presentations on how to “protect your app from hackers”, and unfortunately, both could be summed up in one word:   obfuscate.

Obfuscation is the worst way to secure any software, and Android applications are no different in this regard. If anything, since smartphones today often contain more sensitive and valuable user data then PCs, it is even more important to use real security in mobile apps!

Obfuscation is bad because:

  • It is difficult and costly to implement but relatively easy to break.
  • It prevents, or at least significantly reduces your ability to debug your app and resolve user reported issues.
  • It only needs to be broken once to be broken everywhere, always for any user.
  • Fixing it once broken is almost impossible.

Basically, obfuscation is what security experts call “security by obscurity” which is considered very insecure.

Consider this: the entire Internet, including most banking and financial sites runs almost completely on open source software and standard, open, and documented protocols: Apache, NGINX, OpenSSL, Firefox, Chrome.

OpenSSL is particularly interesting, because it provides encryption that is good enough for the most sensitive information on the net, yet it is completely open.

Even the infamous “Dark Web” or more specifically the Tor network, is completely open source.

Truly secure software design does not rely on others not understanding what your code does.

Even malware writers, who’s entire bread and butter depends on hiding what their apps are doing, no longer rely on obfuscation but instead moved on to full blown code encryption and delivering code on demand from a server.

This is because obfuscated code was too easy for security researchers, and even fully automated malware scanners to detect.

If you want to learn more about this, follow security company blogs such as Semantek, Kaspersky and Checkpoint. Their researchers sometimes publish very interesting malware analysis showing the tricks malware writers use to hide their evil code.

Specifically bad advice

Now I would like to go over some specific advice given in one presentation, that I consider to be particularly bad, some of it to the point where I would call it “anti-advice”:

  1. Use reflection
  2. Hide things in “native”
  3. Hide data with protobufs or similar
  4. Hide code with ProGuard or similar

I listed these “recommendations” from most to least harmful.

If you are considering using any of these technics in your app, please read the following explanation before doing so, and reconsider.

1. Using reflection

Reflection is a powerful tool, but it was not designed to hide code.

If you use reflection to call a method in a class, anyone looking at a disassembled version of your app, or even running simple “strings” utility on it will still see all the method and class names.

You will gain nothing but loose any protection from bugs and crashes that compiler checks and lint tools normally provide.

You could go as far as scramble (or even fully encrypt) the strings holding the names of the classes and methods you call with reflection and only decipher them at run time.

But this takes long time to implement, is very error prone, and will make your app slower since it has a lot more work to do for a single, simple function call.

Stop and think carefully: what would a “hacker” analyzing your app gain from knowing what API you are calling?

The answer will always be: nothing, unless your app is very badly written!

Most security apps, like password managers, advertise exactly what encryption they are using so their customers would know how secure they are.

In a truly secure app, knowing what the app does, will not help a bad guy break it in any way.

I challenge anyone to give me an example in the comments of an API call that is worth hiding in a legitimate app.

2. Hide things in “native”

If you are not familiar with JNI and writing C and C++ code for Android, go read up on it, but not in order to protect your app!

Because Java (and Kotlin) still have performance issues when it comes to certain types of tasks (specifically, games and graphics related code), developers at Google created the Native Development Kit – NDK, to let you include native C and C++ code in your app that will run directly on the device processor and not the JVM (Dalvik / ART).

But just as with reflection, the NDK was not designed to hide your code from prying eyes.

And thus, it will not hide anything!

To many Java developers, particularly ones with no experiences or knowledge developing in native (to the hardware) languages like C,  a SO binary file will look like complete gibberish even in a hex editor.

But, just because you don’t understand what you are looking at, does not mean someone trying to crack your app will have a hard time understanding it!

A so file is a standard library used on Linux systems for decades (remember: Android is running on top of the Linux kernel), so there are lots of tools out there to decompile and analyze them.

But your attacker probably won’t even need to decompile your so file. If all they are looking for is some string, like a hard-coded password or API token you put in your app, they can still see it with a simple “strings” utility, same as they would in your Java or Kotlin code. There is no magic here – all strings remain intact when compiling to native.

Also, any external functions or methods your native code calls will appear in the binary file as plain text strings – your OS needs to find them to call them, so they will be there, exposed just like in any other language!

But things can get worse: lets say you have some valuable business logic in your app, and you want to make it harder for hackers to decompile your code and see this logic.

It is true that when you compile Java source, a lot more information about the original code is preserved than when compiling C or C++.

But don’t be tempted by this, because you may leave your self even more exposed!

If a hacker really wants to run your code for his (or hers) nefarious purposes, then wrapping it up in a library that can easily be called from any app is like gift wrapping it for them.

And this is exactly what you will be doing if you put your code in a native SO file: you are putting it in an easy to use library!

Instead of decompiling your code and rewriting it in their app, the hacker can just take your SO file, and call its functions (that must be exposed to work!) from their own app.

They don’t need to know what your code does, they can just feed it parameters and get the result, which is what they really wanted in the first place.

So instead of hampering hacking, you make it easier by using the wrong tool, all the while giving your self a false sense of security.

4. Hide data with protobufs or similar

By now you should have noticed a pattern: one thing all these bad advice have in common is recommending the wrong tool for the job.

Protobufs is an excellent open source tool for data serialization.

It is not a security tool!

The actual advice given in the presentation was to replace JSON in server responses with protobufs in order to make the information sent by the server less readable.

But what security do you gain from this? If your server sends a reply like this:

{
"first_name" : "Jhon",
"last_name" : "Smith",
"phone" : "555-12345",
"email" : "jhon@email.com"
}

converting this structure to a protobuf will look something like this:
xxxxJhonxxxxSmithxxxx555-12345xxxjhon@email.com
Is that really hiding anything?

Protobufs are more compact then JSON, and they can be deserialized faster and easier than JSON but they also have some disadvantages: they are not as flexible as JSON.

It is hard to support optional fields with protobuffs and even harder to create dynamic or self describing objects.

If your app needs flexibility in parsing server replies, or if you have other clients, particularly web clients written with JS that access the same server API, JSON may be the better choice for you.

When deciding whether to use JSON or protobuffs, consider their advantages and disadvantages for your use case, DO NOT CONSIDER SECURITY!

They are both equally insecure, and you will need encryption (always use SSL!) and proper access validation (passwords, tokens, client certificates) if you want to keep your data safe.

4. Hide code with ProGuard or similar

This advice actually talks about the right tool for a change: ProGuard.

This is a tool Google ships with Android Studio, and it does two things: reduces the size of your code and resources after compilation, and slightly obfuscates your code.

This is not a bad tool, but it comes with a cost, and it won’t really give you protection from hackers.

It will rename your methods like getMySecretPassword() to a() but will that really stop anyone from doing anything bad?

At best, it will slow them down, but keep in mind that it will also cost you:

ProGuard has the side effect of rendering all stack traces useless and making debugging the app extremely difficult.

There is a way to mitigate this: you need to keep a special translation file for every single build of your app (because ProGuard randomizes its name mangling).

If you need to support users in production and don’t want to be helpless or work extra hard when they report a crash, you might want to give up on ProGuard.

Also keep in mind that you need to carefully tell ProGuard what not to obfuscate, since you must keep any external API calls, components declared in the manifest and some third party library calls intact, or your app will not run.

Remember – ProGuard will:

  • Not keep any hardcoded strings safe.
  • Not keep your user password safe if you store it as plain text in your app data folder.
  • Not keep your communication safe if you do not use SSL.
  • Not protect you from MITM attacks if you do not use certificate pinning.

ProGuard might make your final APK file smaller by getting rid of unused code and reducing length of class and methods names, but you should carefully consider the cost of this reduction you will pay when dealing with bugs and crashes.

I find it is usually just not worth the hassle.

And there are better tools now for reducing download size, such as App Bundles.

Summary

Messing with your code will never make your app more secure. It will not protect you from hackers.

Even if you do not want, or can not, release your app as open source, you still need to remember that trying to hide its code with obfuscation will cost you more then having your app reverse engineered.

The development, debugging, and user support costs can be as devastating as any hacks!

But, if you treat your code as though it is meant to be open, and make sure that even if a bad person can read and understand everything your app does they still can not get your users data or exploit your web server, then, and only then, will your app be truly secure.

And doing that is often easier and cheaper than trying to obfuscate your code or data.

P. S.

One of the presentations mentioned a phenomenon I was not familiar with: “App cloning”.

Apparently, if you publish an ad supported app, some bad people can take your app without your permission, replace your advertisement API keys with their own, and release the app to some unofficial app stores like the ones that are common in China (because Google Play is blocked there by the government).

This way, they will get ad revenue from your app instead of you.

But consider this: would you publish your app to these stores?

If your answer is “no”, then you are not losing anything!

You will never get any money from these users because they will never be able to install your original app, so any effort you put in defending against “cloning” will be a net financial loss to you.

Remember – as a developer, your time is money!

P. S. 2

Someone in the audience asked about Google API keys like the Google Maps API key.

Usually, it is bad practice to put API keys in plain text in the manifest of your app, because anyone can get them from there and use a paid API at your expense.

But this is not the case with Google API keys!

The reason Google tells you to put the key in the manifest, is because Google designed these API keys in such a way, that they will be useless to anyone but you, so stealing them is pointless.

This is a great example of a good security design: instead of relying on app developers to figure out how to distribute an API key to millions of users but keep it safe from hackers, Google tide the key to your signing certificate and your app id (package name).

When you create the API key, you must enter your certificate fingerprint and your package name.

Your private key – the one you use to sign your apps for release, is something most developers already keep very safe. There is never a reason to send it anywhere and it would never be included in the app itself.

It will stay safe on the developers computer.

And without this private key, the public API key will not work.

If it is used in an app signed by anyone else, even if that app fakes your app’s id, the API key will still be invalid.

This is how you secure apps!