Setting up the Android SDK on Windows 7 64bit, with a 64bit JDK / JRE is a bit less straightforward than one would expect, thankfully though the solution is quite simple. There are two settings that need to be adjusted to make this work – otherwise you’ll get an error indicating that Java can’t be found.
Step 1: Modify your PATH to include the bin folder of the JRE. Mine looks like this:
C:\Program Files\Java\jre6\bin
Step 2: Set the ANDROID_SWT variable (you’ll probably need to add it) to the \tools\lib\x86_64 folder of the Android SDK. Mine looks like this:
C:\Android\SDK\tools\lib\x86_64
With these two changes, everything seems to work as expected. Why this is required on 64bit but not 32bit I’m not sure, but this does seem to solve the problem.
The definition of a data breach seems to be reasonably straightforward and easy to understand — but that isn’t always the case. LinkedIn is back in the news thanks to a dataset containing profile information for 700 million records being traded among the darker actors on the internet. But LinkedIn is very clear about how they view this situation:
This was not a LinkedIn data breach and our investigation has determined that no private LinkedIn member data was exposed.
During a recent discussion about the DarkMatter CA on a Mozilla mailing list, it was found that their 64-bit serial numbers weren’t actually 64 bits, and it opened a can of worms. It turns out that the serial number was effectively 63 bits, which is a violation of the CA/B Forum Baseline Requirements that state it must contain 64 bits of output from a secure random number generator (CSPRNG). As a result of this finding, 2,000,000 certificates or more may need to be replaced by Google, Apple, GoDaddy and various others.
Earlier this year, a vulnerability was discovered in the Jackson data-binding library, a library for Java that allows developers to easily serialize Java objects to JSON and vice versa, that allowed an attacker to exploit deserialization to achieve Remote Code Execution on the server. This vulnerability didn’t seem to get much attention, and even less documentation. Given that this is an easily exploited Remote Code Execution vulnerability with little documentation, I’m sharing my notes on it.
A couple hours ago, Mike Santillana posted to oss-security about a rather interesting find in Ruby’s OpenSSL library; in this case, the flaw is subtle – so much so that it’s unlikely that anyone would notice it, and it’s a matter of a seemingly insignificant choice that determines if your code is affected. When performing AES-GCM encryption, if you set the key first, then the IV, and you are fine – set the IV first, you’re in trouble.
For the second year I am publishing a year-in-review – something I had generally avoided in the past, as the tone of these posts is typically just cynicism and negativity. Looking back at 2015, it wasn’t all positive (what year is?), but there was certainly some good, and there are great things to look forward to.
In a season filled with empty marketing pitches, worthless predictions, and pointless projections – it’s important to look at the good and avoid the cynicism overload that is all too common.
