2015-12-18

Developer INFOSEC in a Post-Sony era


There's going to be a dev-conference in Bristol in February, voxxed days bristol;
where I'll be presenting my Hadoop and Kerberos tak,
, maybe with a demo of the Slider kdiag command, which after a couple of iterations I intend to move into Hadoop core as part of HADOOP-12649: Improve UGI diagnostics and failure handling. Any version which gets into hadoop core will be able to use some extra diagnostics I hope to add to UGI itself, such as the ability to query the renew time of a ticket, get the address of the KDC and probe for it, maybe more. Because Kerberos doesn't like me this week, at least not with zookeeper.

It should be a fun day and local developers should think about turning up. I was at the last little developer bash in November, where there was a great mix of talks ranging from the history of the Transputer to the challenge of implementing a mobile-app only bank.

Illumination

What apparently hasn't make the cut is my other proposal, Household INFOSEC in a Post-Sony era. Which is a shame, as I have the outline of a talk there which would be seminal. This wouldn't a be a talk about platitudes like "keep flash up to date", it'd be looking about my rollout of a two-tier network, with the IoT zone hooked directly up to the internet by the router provided by the ISP, and a DD-WRT router offering a separate trusted-machine subnet and high-entropy-passworded, no-SSID-published wifi network restricted to devices I can control.

What I was really going to talk about, however, was how we are leaking personal information from all the devices we use, the apps we host in them, the cars we drive, the cameras we use (guess whose camera app considers camera GPS and timestamp information non-personally identifiable and hence uploadable? That's right: Sony). We leak that information, it gets stored elsewhere, and we now depend on the INFOSEC capabilities of those entities to keep that data private. And that's hard to pull off —even with Kerberos everywhere.

One aspect of my homework here is working out what data I have on my computers which I consider sensitive.

There's photos, which are more irreplaceable than anything else: my policy there is Disaster Recovery: using Google Photos as the off site backup; a local NAS server in the trusted subnet for on-site resilience to HDD failures. That server is powered off except for the weekly backups, reducing its transitive vulnerability to any ransomware that gets onto into the trust zone.

There's passwords to web sites, especially those with purchasing rights (amazon, etc), and financial institutions (paypal, banks) —in the UK my bank uses its chipped debit cards as the physical credential for login and cash transfer, so it's fairly secure. The others: less so, especially if my browser has been intentionally/unintentionally saving form information with things like CVV numbers.

And what else matters? I've come to the conclusion it is the credentials needed to gain write access to the ASF source code repositories. Not just Hadoop —it's the Ant source, it's slider, it's anything else where I am creating code where any of the following criteria are met
  1. The build is executed by a developer or a CI tool on a machine holding information (including their own credentials) to which someone malicious wants access.
  2. The build is executed by a developer or a CI tool on a machine running within a network to which someone malicious wants access.
  3. Generated/published artifacts are executed during a build process on a machine/network to which someone malicious wants access.
  4. The production code is executed somewhere where there is data which someone malicious wants to get at or destroy, or where adverse behaviour can the system is advantageous to someone malicious.
You can point to the Hadoop stack and say: it's going that way —but so is the rest of the OSS codebase. The LAMP stack, tomcat web servers, Xerces XML parsers, open office, linux device drivers, clipboard history savers like glipper, Python statistics libraries, ... etc. We live in a world where open source is everywhere from the datacentre to the television. If anyone malicious has the opportunity to deliberately inset vulnerabilities into that code —then they get to spread them across the planet. That source code then, is both a juicy target for anyone looking for 0-day exploits, but also for inserting new ones.

We've seen attacks on Kernel.org, and the ASF. With the dominance of git as the SCM tool, and it's use of SHA-1 checksums, the value of breaking into the servers is diminishing —what you need to go is get the malicious code checked in, that is: committed using the credentials of an authorised developer.

That'll be us then.

More succinctly: if the Internet becomes the location of an arms race, we're now targets en route to strategic goals by entities and organisations against whom we don't stand a chance.

How do you defend against nation states happy to give away USB-chargeable bicycle lights at an OSS conference? Who have the ability to break through your tier-3 ISP firewall and then the second level DD-WRT router that you never locked down properly and haven't updated for three weeks. We're don't stand a chance, not really

No doubt I'll come over as excessively paranoid, but its not as if I view my personal systems a direct target. It's just the source code repos do which I do have access are potentially of interest. And with other people in the Hadoop space building those same projects, something injected into the build using my credentials then has transitive access to everyone else who checks out and builds the same codebase. That's what worries me.

WTF do we do?

Short-term I'm switching my release process to a VM that's only ever used for that, so at least the artifacts I generate aren't indirectly contaminated by malware; I also need to automate a final SHA1 audit of every dependent artifact.

Medium term: I need to come up with a plan for locking down my git ssh/svn credentials and passwords so they aren't trivially accessible to anything malicious running on any laptop of mine. I know github is moving to 2FA and U2F auth, but that's for web and API auth: not git repo access. What the Linux Kernel team have is a much better story: 2FA for granting 24h of write access from a specific IP address.

Long term: I have no idea whatsoever

[photo: two Knog lights you charge up via USB ports. We should all know to be cautious about plugging in untrusted USB sticks —but who would turn down a freebie bike light given away at an OSS developer conference?]

2015-12-04

Remembering the glaciers: Greenland

In July 2012, while wandering around on a flight to the US, I looked out the window and got to see what Greenland looks like from above.
Untitled


When this ice melts, it raises the ocean.

Untitled

And the mountains will be bare rock, as they have not been since before the ice ages began.

Untitled

There's something deeply tragic about a planeload of people, sitting in their seats, windows shuttered, watching the videos streamed to keep the populace happy —while if they chose to look up they could see the great icefields melting. Arguably, that's a description for society as a whole —and all of us in it.


2015-12-03

Remembering the glaciers: Fox Glacier, New Zealand


The southern hemisphere has its own ice. I can't find any of my 1994 Peru/Chile expedition photos, so nothing of the Southern Patagonian Ice Cap, the Torres del Paine or snow-capped volcanoes.

Instead, here's one from New Zealand, the Fox Glacier.

fox_glacier

This was on South Island, somewhere down the west coast, December 1998.

What's impressive here is how it comes down almost to sea level: we were staying nearby and this was a short and mostly flat walk from where we were staying. It's in the temperate rain forests of the region. The fact that the entire valley looks fairly glacial implies that its been bigger in the past -like many of the other Fjords on the island, it shows the glaciers once made their way out to a lower sea level. (the same goes for Scottish sea glens, presumably)

The whole glacier was making the sound of gently running water, right down by the terminal moraines. Apparently this glacier actually advanced between 2005-2009, but it's retreating again.

[Team: Steve, Bina]
[Photo: Fujichrome ASA100 slide (presumably) on an olympus zoom-lens compact camera I'd bought in NZ]

2015-12-02

Remembering the Glaciers: Mont Pelvoux

Mont Pelvoux, Massif des Ecrins, French Alps

Pelvoux

This was about two thirds through what turned out to be 14 hours on the move: out the mountain hut before 5 am, making our way up to the summit up a couloir from the south-west, continuing up the ice field, then continuing over the mountain and descending the other side. This was part of the descent, looking up at where we'd been: Glacier du Pelvoux.

Seracs are the waterfalls of glaciers; the ice may move a centimetre or two a day, but it doesn't do it smoothly: slowly the serac moves out past the rocks, building up weight until eventually its so heavy that the overhanging part —and usually a section behind— separates from the rest of glacier and starts to break off. Those cracks expand, and eventually the serac itself falls. I've never seen or even heard that, but it's something you fear. Hence you get up early and move fast.

This was the first time I'd had to descend seracs, downclimbing front pointing the crampons with you needing the clear the base as it opened up into a deeper crevasse. We used ice screws for protection, with body belays; we were already roped up for glacier work in general. The last person in the group had to make do with the in-situ protection, which was inevitably some iced up piece of wood. They were of course backed up by the people below, but even so: glad it wasn't me.

Google earth shows this peak in all its intensity.

I don't think I do this any more; not just the technical aspects, or the terrifying exposure on the way up, but 14 hours of continuous movement on the mountains is pretty brutal. My body just wouldn't cope, not given my knee hasn't recovered from its 2006 shredded tendon, and I doubt I have the endurance this or even for the 12 hour non-stop drive from the channel to the alps. I'm never going to get a chance to take this photo again.

[Participants: SteveL, Will W, ^Jim, Mark S]
[Photo: Ilford B&W with Canon Sureshot, manual D&P onto Ilford A4 paper, with manual dodge/burn for the sky]

2015-12-01

Remembering the Glaciers : Sunset over Mont Blanc

Sunset over Mont Blanc

Sunset over Mont Blanc.

From the west, obviously; Will and I had turned up with our bikes near Les Contamines and haggled over how much it would cost us to camp there. We'd already eaten, so all we were paying for was a shower. They gave us a discount in exchange for making us camp in the far corner and not tell anyone what we'd paid. Given the next two days our bathing facilities were mountain streams of meltwater a few minutes off the ice, the FFr we paid for the shower was worth it.

Wikipedia tells me that that the date was 21 June, 1997. We'd been up Col de la Columbiere that morning to catch a mountain stage of the Tour de France. Pantani won the day, with Col de Joux Plane being the big finale.

We were heading in the opposite direction: south on gravel tracks over to Lac Du Roselend, then continuing a partial bike circuit of Mont Blanc.

Imagine what this would look like without the ice? Still dramatic, but red in the sunset?

[Participants: Steve L, Will W]
[Film: Fujichrome 100ASA slide+ Canon Sureshot compact]