All posts by Michael Battaglia

Michael is a senior programmer for Multi Data Services in NY. Coding not just his day job, it is his passion.

Stagefright Gives Android Users Something to Fright About

A few months ago people were talking about the latest bug  in iOS that would cause the phone to crash if someone sent a specific set of characters via a text message (which has been fixed).  Now it appears that it is Android’s turn.  This new bug is being called Stagefright which allows an attacker to remotely execute code on another person’s Android device that they received via MMS messages.

The exploit was publicly announced on July 27, 2015 by the security firm Zimperium.  Researchers say that the bug originated in a core component called “Stagefright” which is a library that is used to play various multimedia formats that are integral in displaying the contents included in MMS messages.  The reason why this issue is so serious is because that it can execute on a user’s device without you actually doing anything.

Furthermore, this bug has been in the Android operating system since version 2.2 which means that roughly 1 billion devices can be potentially infected with malware due to this flaw.  While Google and Samsung are working hard to push out a security fix to ultimately patch this bug, Zimperium has released an app that can be installed on your device to check to see if your Android device has been infected.

If you want to learn more about this bug, watch the video below which demonstrates the Stagefright bug:

 

Why Your Car Is Insecure

You may not know this, but most of you drove into work today in a computer.  Don’t believe me?  Oh, maybe because you commonly refer to it as your car.  For the past 40 years car manufacturers have been making cars with computers that typically are located in proximity to the automobiles engine.  The on-board computer controls many things including fuel injection, the anti-lock braking system (ABS), gear shifting, and diagnostics (you know, the infamous check engine light) to name a few.

However over the past decade manufacturers have started to add more smarts into the cars, specifically to the entertainment system.  Bluetooth, iPod and USB connectors, as well as WiFi all add the ability to connect 3rd party devices to your car.  As consumers we have taken all of these new features for granted but now we are going to need to rethink these capabilities because they are being used also as attack vectors for hackers.

Over the past year more and more reports have been surfacing regarding groups of people who have been able to successfully hack into the car’s computer and expose some serious exploits.  Last month Chrysler recalled 1.4 million of Dodge Rams, Vipers, Durangos, Chargers and Jeeps due to a flaw in their UConnect entertainment system which could allow an attacker to gain control of critical functions such as braking, steering, speed control, and the transmission.  Then this week Tesla Model S cars pushed out a patch to a flaw that could allow hackers to take control of the vehicle (The details of this hack will be announced during Def Con).  I am pretty sure that we will be hearing more car hacks relating to other car makers in the up coming months too.

The major problem is that there is a design flaw in the how the components in the car connect to the computer.  They use a standard protocol called CAN bus which is similar to the internal bus in typical computers.  Car manufacturers say that the components are “firewalled” from the entertainment system but clearly this isn’t enough.  They need to go back to the drawing board and physically separate the entertainment system from the CAN bus and this will prevent these types of attacks from happening in future model cars.  But there is no word yet whether or not manufacturers are going to be taking this route.  For now if you get a recall letter for your car you should always take it seriously and get your car fixed, regardless of the reason.

Moore’s Law: Its Days are Numbered

This year marks the 50th anniversary of the famous computer observation known as Moore’s law.  Moore’s law is named after the co-founder of Intel, Gordon Moore, which predicted that the number of transistors that you can print on integrated circuits (or ICs) doubles roughly every 18 months.  This law has been consist with the industry trend over the past five decades and as a result we have enjoyed the outcome of faster, smaller, and less expensive components used in computers.


Gordon Moore

However it looks now that Moore’s law may be in trouble.  As we have developed smaller and smaller transistors in the last few years we are now getting down to the nanometer (nm) level in terms of size.  To give you an idea how small a nanometer is if you blew up 1 nanometer to the size of a meter stick (about 3 feet) 1 meter in comparison would be over 600 miles long.  This is roughly the driving distance from New York City to Detroit!

The issue when you start working on these small sizes is that the chip manufacturers have to deal with issues on the quantum level.  Electrons start doing funny things such as spontaneously coming into and out of existence (also known as electron tunneling).  There are also current leakages that cause the chip to incorrectly report a gate as set as open even though it is supposed to be closed.  These ill effects prevent the making of reliable ICs.

But chip makers are not ready to throw in the towel yet.  Currently Intel is down to the 14nm which is about the width of about 150 atoms.  Furthermore, there was a report from IBM a few weeks ago saying that they have been able to cut that number in half to 7nm.  But at some point it looks like we may not be able to get any smaller and it may be sooner than we think.

Tail Call bug Discovered in .NET 4.6

If you have begun using Visual Studio .NET 2015 you might want to hold off.  There is a serious bug that was discovered in .NET Framework 4.6 64 Bit optimizer that affects the last parameter that is placed in the tail call of functions.  This bug is simply being referred to the tail call bug (https://github.com/dotnet/coreclr/issues/1296).

To understand what this bug is you need to know a few things about tail calls and how compilers work in general.  First we will cover what a tail call is.  When you write a function in any modern language, may times you can have your return value be a return value from other function.  An example is demonstrated below:

function foo(data)
{
a(data);
    return b(data);
}

In the above example, the function foo() calls two functions, a() and b().  However the value from the function call b() is returned from foo().  This means that the call to b() is consider to be the tail call.  Your function can have multiple tail calls as demonstrated below:

function bar(data)
{
    if (a(data))
        return b(data);

    return c(data);
}

In this example, b() and c() are tail calls but a() is not.  You can read up more on tail calls here: https://en.wikipedia.org/wiki/Tail_call

The next topic to cover is code optimization.  When you compile your programs in most modern languages it will analyze your code and attempt to see if there is anything that can be substituted with a simpler set of instructions.  Please consider the following:

int a = 1 + (2 * 8);

An optimizer will see this and replace it with the following line before it creates the output assembly:

int a = 17;

As you can see that the final result of the variable a would be exactly the same but the code in the later example would execute faster.  For the case of the bug that is happening with .NET is affecting the optimization related to the last parameter of the tail call.  What is interesting about this bug is originating in the new RyuJIT which is supposed to affect 64 Bit versions of assemblies (http://blogs.msdn.com/b/dotnet/archive/2013/09/30/ryujit-the-next-generation-jit-compiler.aspx).

So now the question is what to do?

Well you can wait for this bug to be fixed.  Microsoft is working on a fix (https://github.com/dotnet/coreclr/pull/1298) but there is no word yet on when this will be released.

You can also disable the RyuJIT optimization by updating your registry: Under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework add a useLegacyJit DWORD with a value of 1.  After Microsoft does release the patch for this bug you should change the value back to 0.

Source: http://nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/

Update (7/30/2015 @ 10:18 AM EST): 

The bug has been fixed and the patch has been made but it won’t be available into the next Windows Update.  No word yet on when this will be.  Rich Lander, who works on the Microsoft Common Language Runtime team, posted this:

Could C# be the one language to rule them all?

Being a developer, it is important to continue to learn about new languages as you are being asked to create solutions for multiple platforms.  The reason why we have so many languages is because on a hardware level each CPU uses a different assembly language to run their instructions.  Due to this fact not every language is able to run on every platform.  For this to work you would need to have multiple companies that are able to understand these CPU differences to write compilers for the same language.

Java_1

For a time, the language Java (which as owned by Sun Microsystems for a time until Oracle purchased the company) was set out to solve this problem.  From 1995 through the mid 2000’s it seemed like Java was supported on almost every computer and device.  That was until the iPhone come along with its first version of iOS in 2007.  It wasn’t unusual that a new device didn’t have support for Java on the initial release but then Apple announced that they will never support languages like Java (http://www.iphonefaq.org/archives/9731).

The reason is because their terms of use do not allow developers to create apps that were written from interpreted code.   So that means you are only able to create apps that are written in a low level language like Objective-C which create compiled programs.  This was bad news for developers as there was one more language that we needed to learn.

The folks over at Google decided on using Java (although you can also use C++) to write your mobile apps for their Android operating system.  Meanwhile Microsoft relies on their .NET Framework to create Windows Mobile apps which includes the Visual Basic .NET and C# languages.

By now you see the problem.  If you wanted to write a mobile app for each of these platforms, you would need to learn three different language on three different frameworks.  Wouldn’t it be nice if someone created a new language and would allow programmers to create apps for all of these types of devices?  Well the short answer is no.

xkcd-standards

The solution to this problem has been solved for us already by the Mono group (http://www.mono-project.com/).  The Mono project was started back in 2004 as an open source project to port the .NET Framework to run on Linux and Mac.  This project was original independent from Microsoft but now it is being included in the latest version of its developer environment: Visual Studio 2015.

VS2K15_1

This is all possible because of Xamarin (http://xamarin.com/) which takes the ported version of the .NET Framework and uses it build apps that run on both Android and iOS devices.  However it isn’t perfect.  For instance, in order to create iOS apps in Visual Studio 2015 you are going to need to purchase a business account from Xamarin ($89/month) plus have access to a Mac.  This will then create the compiled programs that iOS will allow to run on its devices.

Also the version of the ADK (Android Development Kit) that is included with Visual Studio 2015 isn’t the latest version so you will need to manually go out and download and configure the latest version on your machine before you are able to create Android apps.  At any rate you will be prompted to log into Xamarin.  You can find more information about this here: https://www.visualstudio.com/en-us/features/xamarin-vs.aspx.

Not exactly plug in play, but it is still early days.  Hopefully, future versions of Visual Studio will allow developers access to a more “turn key” solution for creating mobile apps in a single programming language.