Friday, December 19, 2014

Some links for understanding CVE-2014-9390

This is a particularly interesting CVE for me, because it's "right up my alley", as they say.

  • Git, 1.9.5, 2.0.5, 2.1.4 and 2.2.1 and thanking friends in Mercurial land
    Git maintains various meta-information for its repository in files in .git/ directory located at the root of the working tree. The system does not allow a file in that directory (e.g. .git/config) to be committed in the history of the project, or checked out to the working tree from the project. Otherwise, an unsuspecting user can run git pull from an innocuous-looking-but-malicious repository and have the meta-information in her repository overwritten, or executable hooks installed by the owner of that repository she pulled from (i.e. an attacker).
  • [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)
    Fixes since v2.2
     * We used to allow committing a path ".Git/config" with Git that is
       running on a case sensitive filesystem, but an attempt to check out
       such a path with Git that runs on a case insensitive filesystem
       would have clobbered ".git/config", which is definitely not what
       the user would have expected.  Git now prevents you from tracking
       a path with ".Git" (in any case combination) as a path component.
     * On Windows, certain path components that are different from ".git"
       are mapped to ".git", e.g. "git~1/config" is treated as if it were
       ".git/config".  HFS+ has a similar issue, where certain unicode
       codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
       it were ".git/config".  Pathnames with these potential issues are
       rejected on the affected systems.  Git on systems that are not
       affected by this issue (e.g. Linux) can also be configured to
       reject them to ensure cross platform interoperability of the hosted
     * "git fsck" notices a tree object that records such a path that can
       be confused with ".git", and with receive.fsckObjects configuration
       set to true, an attempt to "git push" such a tree object will be
       rejected.  Such a path may not be a problem on some filesystems
       but in order to protect those on HFS+ and on case insensitive
       filesystems, this check is enabled on all platforms.
    A big "thanks!" for bringing this issue to us goes to our friends in
    the Mercurial land, namely, Matt Mackall and Augie Fackler.
  • 3f1509809e728b70ea7912e4e1b40f22965e45ee
    fsck: complain about NTFS ".git" aliases in trees 
    read-cache: optionally disallow NTFS .git variants 
    path: add is_ntfs_dotgit() helper 
    fsck: complain about HFS+ ".git" aliases in trees 
    read-cache: optionally disallow HFS+ .git variants 
    utf8: add is_hfs_dotgit() helper 
    fsck: notice .git case-insensitively 
    t1450: refactor ".", "..", and ".git" fsck tests 
    verify_dotfile(): reject .git case-insensitively 
    read-tree: add tests for confusing paths like ".." and ".git" 
    unpack-trees: propagate errors adding entries to the index
  • Git vulnerability with .git\config
    Normally the git client avoids ever overwriting that file. Even if you commit a .git\config file and push it to a shared repo, no one else’s Git client will check it out into their private repos. However, a bug was discovered where various permutations of the .git folder name (e.g. mixed case, gIT, GiT, etc, Windows filename shortening .git~123, Ignorable Unicode codepoints .g\u200cit\config, etc) were not caught be the Git client’s filtering logic. As such, if someone pushed a malicious config file with one of these permutations, other people’s Git clients would check them out, overwriting their personal config file and hijacking their Git commands. This affects, at least, Windows NTFS and Mac OS X HFS+ filesystems, both of which are case insensitive filesystems.
  • Vulnerability announced: update your Git clients
    Repositories hosted on cannot contain any of the malicious trees that trigger the vulnerability because we now verify and block these trees on push. We have also completed an automated scan of all existing content on to look for malicious content that might have been pushed to our site before this vulnerability was discovered. This work is an extension of the data-quality checks we have always performed on repositories pushed to our servers to protect our users against malformed or malicious Git data.

Some resources for trying to understand the SPE hack

If you're trying to make sense of it all, here are some fairly well-reasoned essays, from a variety of smart people:

  • North Korea and the attack on Sony Pictures Entertainment
    In HPSR Security Briefing Episode 16, we profiled North Korea’s cyber threat landscape, highlighting the regime’s known capabilities and deficiencies in cyberspace. In that report, we noted North Korea’s initial response to The Interview. Based on our previous research of North Korean cyber capabilities, it is difficult to discern whether the regime acted alone. It is plausible that the actors responsible for this attack relied on the assistance of an insider.
  • FBI: North Korea to Blame for Sony Hack
    While the United States government seems convinced by technical analysis and intelligence sources that the North Koreans were behind the attack, skeptics could be forgiven for having doubts about this conclusion. It is interesting to note that the attackers initially made no mention of The Interview, and instead demanded payment from Sony to forestall the release of sensitive corporate data. It wasn’t until well after the news media pounced on the idea that the attack was in apparent retribution for The Interview that we saw the attackers begin to mention the Sony movie.
  • Lessons from the Sony Hack
    This could be any of us. We have no choice but to entrust companies with our intimate conversations: on email, on Facebook, by text and so on. We have no choice but to entrust the retailers that we use with our financial details. And we have little choice but to use cloud services such as iCloud and Google Docs.
  • Did the DPRK Hack Sony?
    Drawing positive conclusions from the public evidence is incorrect. The NSA and the CIA may (or may not) have many other details they'll never disclose. The much-ballyhooed language setting, for example, is completely useless.
  • Why it's possible North Korea was behind the Sony hack
    NSA analysts might start with what’s known as “flow records,” which are very similar to Netflow. Each of these records details a communication between computers and the ports they used to initiate said communication. It might read something like this: "Computer A, port X sent K bytes of data to computer B, port Y between T0 and T1". Although flow records are the simplest data collected by the NSA’s wiretaps, it’s a powerful tool for tracking online activity.
  • What is happening?
    It's not about a movie or even Sony, at all. When you build a nuclear program, you have to explode at least one warhead so that other countries see that you can do it. The same is true with Cyber.
  • goodbye horses
    I suppose the more nuanced point Dave is trying to make, is not so much that this is an Act of War, or even that it should be. But more that this Sony thing is not about Sony, it's about the US necessarily having to prepare for a future where it will have to politically and publicly address and respond to a game that up until very recently, was only played in the shadows.

Hacker School publications are quite impressive

Somehow I stumbled across the inaugural issue of the Hacker School journal: Code Words: A quarterly publication about programming from Hacker School.

I haven't had time to read the entire issue yet, but so far I'm really pleased.

You know that you're really reading a publication targeted at programmers when the first paragraph of the first article is as follows:

Floating point is a giant mess. There are known best practices for most issues that come up in everyday use (e.g., using Kahan summation or adding stochastic noise to reduce aggregate numerical error), but there are still corner cases. Different libraries and implementations give different results because there’s no generally accepted standard.

"Numerical error"? "Kahan summation"? "Stochastic noise"?

Oh, yes, yes, YES! Bring it on!

And I also really enjoyed An introduction to functional programming, with its straight-forward, plain-english approach:

When people talk about functional programming, they mention a dizzying number of “functional” characteristics. They mention immutable data, first class functions and tail call optimisation. These are language features that aid functional programming. They mention mapping, reducing, pipelining, recursing, currying and the use of higher order functions. These are programming techniques used to write functional code. They mention parallelization, lazy evaluation and determinism. These are advantageous properties of functional programs.

Ignore all that. Functional code is characterised by one thing: the absence of side effects. It doesn’t rely on data outside the current function, and it doesn’t change data that exists outside the current function. Every other “functional” thing can be derived from this property. Use it as a guide rope as you learn.

They seem to be off to a great start, so I'm hoping that Hacker School continue to find success, and continue to publish more issues of their journal.

Meanwhile, reading the journal led me to the Hacker School blog, which seems pretty great too; I particularly like their "Read Along" feature, in which they select a research topic each week, post a pointer to the paper with some introductory thoughts, and encourage the audience to read along with the paper and contribute their own reactions.

If you're looking for some good reading to strengthen and extend your programming skills, give the Hacker School publications a try!

I suppose I should pay more attention to my investments...

Frankly, I don't monitor my retirement accounts anywhere near as closely as I should.

Who has the time?

But I do try to look at them every quarter or so, to think about how they are doing and what I should change, if anything.

So I signed on and looked at my IRA, and was reading through the various positions.

And I noticed information for a company I'd never heard of!

How did a company I'd never heard of appear in my account? Did I fumble-finger some trade, months ago? Was I hacked? The "purchase history" for the new company showed three apparently legitimate trades, dating back to 2011.

Then I did some web surfing, and arrived at: Kimberly-Clark Announces Details for Completion of Kimberly-Clark Health Care Spin-Off

Kimberly-Clark Corporation (NYSE: KMB) today announced the record date, distribution date and distribution ratio for the previously announced tax-free spin-off of its health care business. The spin-off will form the new publicly traded company, Halyard Health, Inc. Kimberly-Clark also increased its 2014 share repurchase program to take into account expected proceeds as a result of the spin-off.

Kimberly-Clark shareholders will receive one share of Halyard Health common stock for every eight shares of Kimberly-Clark common stock held as of the close of trading on Oct. 23, 2014, the record date for the spin-off.

And, sure enough, the dates of the three trades are precisely the three occasions on which I purchased Kimberly-Clark stock in my IRA.

The computers had quietly taken care of it all.

But, really, I ought to pay more attention to my retirement accounts.

Maybe next year, he says...

Wednesday, December 17, 2014

In which I try to learn more about things I don't understand.

Building on this post of a month ago, and also closely related to Behind the Beautiful Forevers, today I came across a fascinating article on Quartz: The secret to the Uber economy is wealth inequality

These luxuries are not new. I took advantage of them long before Uber became a verb, before the world saw the first iPhone in 2007, even before the first submarine fibre-optic cable landed on our shores in 1997. In my hometown of Mumbai, we have had many of these conveniences for at least as long as we have had landlines—and some even earlier than that.

It did not take technology to spur the on-demand economy. It took masses of poor people.

It's a fascinating article, and not too long.

Well worth reading.

Tuesday, December 16, 2014

Those who do not remember history...

... or something like that.

Anyway, BIG STORM UPDATE: California Drought Situation Improves says:

The much anticipated big storm that hit California on December 10-12 lived up to its expectations with torrential rains, heavy snow in the Sierra, and high winds (although these were not as powerful as forecast). A small tornado (EF-0) even touched down in South Los Angeles Friday morning, December 12th. Rainfall in the San Francisco Bay Area was especially impressive with San Jose picking up 3.23” on December 11th, its 3rd greatest calendar day rainfall on record (POR since 1893). Venado, in Sonoma County, received 9.44” in 24 hours. What was most welcome, however, was that the heavy rain also drenched the southern portions of California including the Central Valley, erasing the seasonal precipitation deficits that were still in place just a week ago.

but also notes that:

Although neither of these changes are any guarantee that the winter will continue to be a wet one, they are at least a good sign. The RRR (‘Ridiculously Resilient Ridge’) that has been the hallmark of drought is nowhere in sight (for the time being). Of course, this is the way the season of 2012-2013 began when a very wet November and December came to an end by January when the RRR set up and didn’t let go for the following two years.

Oh, yes, we remember that well.

The story mentions Venado, a place I've never been. Mill Creek Road looks like it would be a fun drive on a nice summer day. I'll have to try that sometime...

Meanwhile, though, the state is still bone dry, so: let it snow, let it snow, let it snow.

Tuesday, December 9, 2014

Markov chain humor

On the heels of last year's git man page generator, we now have:

  • The Doom that Came to Puppet
    Posts generated by a Markov chain trained on the Puppet documentation and the assorted works of H. P. Lovecraft. Created by @branan using barrucadu/markov. Inspired by King James Programming.

Very, very geeky.

But quite humorous (assuming you know a little bit about Lovecraft and a little bit about Puppet).

Here's a nice example:

“As our guarded messages stated, we rested at midnight after our day of terror and bafflement—but not without a tentative plan for one or more specific features”