Home  |  About  |  Contact

Wednesday, 15 Jul , 2015

Living Dead Software – Why the long goodbyes?

Share this article

2003 Server is dead, Flash is mortally wounded, but they’ll stick around like decaying zombies for many years to come. The 500 word snacklets of security opinion and advice don’t usually offer much in the way of practical solutions. Bearing that in mind, Alex Stamos (formerly security supremo at Yahoo, now at Facebook), has done […]

2003 Server is dead, Flash is mortally wounded, but they’ll stick around like decaying zombies for many years to come.

The 500 word snacklets of security opinion and advice don’t usually offer much in the way of practical solutions. Bearing that in mind, Alex Stamos (formerly security supremo at Yahoo, now at Facebook), has done a cracking job with less than 140 characters:
[tweet https://twitter.com/alexstamos/status/620306643360706561 hide_thread=true width=’900′]
Couldn’t agree more. He is in a good position to understand whether Adobe’s Flash is salvageable, or if it’s like one of those never-ending, budget-blowing, public sector IT projects that no-one has the nuts to nix.
Stop fire-fighting, or perhaps more pertinently, recognise it never worked because your hose was full of holes. Kill/rebuild Flash and bingo – a dramatic improvement for all of us.
Ummmmm
Won’t Flash just pass the most vulnerable/exploited baton to Java, who’ll pass it to WordPress (often via poorly developed, perhaps Java enabled, plug-ins), who’ll pass it to a Microsoft OS, who’ll swiftly hand it off to a bit of the I O[MG] T? I’m not FUD-generating. I’m just reflecting variably reported reality.

What stops ‘better’ solutions falling victim to the same problems?

Surely it’s just a function of the size and quantity of desirable prizes linked to a given bit of widely used software? Good old cost/benefit and economies of scale. Finding hidden holes (or making brand new ones) might be super specialist and effort intensive work, but if it opens most internet accessible devices up to exploitation…well that maths ain’t hard.
And that’s not the only multiplier. The bad guys will ‘borrow’ or buy each others’ tools (as it seems happened with the Hacking Team debacle and many other breaches), so having a go becomes an equal opportunity activity (in dark free market terms). Then there are the good guys. Our developers. Recycling poorly written chunks of code, or writing sub-standard code, again and again and again (I know that’s just a part of the bigger bad software picture – bear with me)….


How much of Flash’s dire rep and pwnable reality is down to it being such a big-assed, lucrative target and how much is down to it just being inherently holey?


In some ways it doesn’t matter. Alex’s suggestion works either way. If you’re constantly outgunned and outnumbered, or it becomes clear your weaponry and/or battle plan is fundamentally flawed, falling back and regrouping makes sense….unless strategic smarts and an interest in the common good are in short supply among the super-senior shot callers.
A WW1 analogy works pretty well here. We, the consumers with data sitting behind fragile software barricades, are much like cannon fodder. Privileged generals and politicians move millions of pieces around on a board. Behind that layer of abstraction, far more attention is paid to maintaining their lifestyle and post-war career prospects than preserving our digital lives.

What might matter?

Folk like Steve Jobs (linking to his now famous ‘Thought’s on Flash’ open letter) and Alex Stamos championing decisive change. Bodies who sway board level opinions and influence the people building software. If I was developing an app right now, or planning future upgrades, would I be avoiding Flash like the plague? <That’s almost, but not quite rhetorical.
68a68789-03f4-4c68-b1e6-3dfab76f70abSo how much of a hit would this be on Adobe? Why should they bother with the drama of euthanising Flash (I had to be allowed just one pictorial reference to the namesake!), when within similar timescales they could release something fundamentally less sieve-like, with a reasonable shelf-life?
If the Flash-killing process would likely take longer than producing something new (see every Microsoft server OS for info) and support contracts could carry on, why the heck would they bother with the grand gesture? It’s naturally wending it’s merry way towards software hell (via a few Faustian circles of nightmarish stuff for users), without that shove down the stairs.

Why the long software goodbyes?

Where is Flash now? Not on your Apples (unless you put it there), not on YouTube (if you choose to avoid it), not in Microsoft products (in future), not on Facebook (for much longer by the sounds of it) and it’s been categorically banished from Firefox. For the pockets of persistent use, there’s the option of some easy config and browser juggling to mostly avoid and occasionally (if really necessary), use it safely. Perhaps, while you’re waiting to see if the big boys will excise it, have a go at cutting it out yourself. But most of that requires effort, effort most end users don’t feel motivated to make.
Long_Goodbye2In those hefty corporate networks, some Flash use might be obscured by the sheer size, complexity and legacy-ness, but there are various discovery and inventorying means to find out where it’s holed up (scuse the pun). Then how does that stack up against other development and security priorities?
2003 server (it’s end of life now in case you haven’t heard), should be a darn sight easier to spot, but will likely be a wee bit harder to get rid of. It rather depends what you’ve cornered yourself into building on top of it and related effort needed to de-bespoke and generally untangle things.
Outside today’s news that’s really the bigger consideration…how do we reduce the need for monster balls, budget and board-level bargaining chips before we can quickly retire end of life and persistently swiss-cheesy software? Do we need to put more effort into defining ‘enough’s enough’ benchmarks? Do we need to build-in more contingency?
Alternatively, should we just stop being surprised that expensive software from household name companies is built full of holes. An open secret that subtly, gently, but persistently manipulates us into paying for extortionate support? Software that frequently has a vulnerability (or ten) that no-one has heard of…not anyone…absolutely zero people – apart, perhaps, from diligent developers or security assessors and the people they tried to tell about bugs, who ‘suggested’ they release the software anyway.
Or (and here’s a novel suggestion), could folk throw their backs into more secure development and truly effective internal/external oversight of insecurity-creating slapdash rushes to release stuff…
…NAH, I’m being daft.
Build stuff that isn’t broken when you sell it!? That makes NO sense.


Coming back from that cynicism fest

I’ll leave you with one request:
Check out Josh Corman (CTO of Sonatype and co-founder of I Am The Cavalry), talking about culture, behaviour and secure, rapid, responsible, profitable development…really, make time. Pour a coffee (or other beverage of your choice) and watch it.

It outlines a rational achievable aim for software vendors, companies who develop their own stuff…
…and THEIR CUSTOMERS.
To put the bold, capitalised and underlined bit in perspective, I Am The Cavalry focuses on vulnerabilities that threaten critical infrastructure and/or lives: Power, water, aviation, road, rail, medical devices etc. If you think the massive risks guarantee every effort is already made to keep those things supremely secure, think again. At the other extreme, what relevance has that got to a ‘Flashed-up’ chucked together mobile app? Think about the pictures, contact details and private things your kids might have stored on the same device.
It should therefore seem like a no-brainer, but it can only work in a culture that lets execs shed short-termist cost and speed blinkers. Then and only then it may be possible to move towards ethical, quality-generating and ultimately more profitable innovation.

Where and to whom does the GDPR apply?

Yeah, I doubted my sanity going at this one too, but here I am, because working out whether or not the GDPR would apply in different practical and geographical circumstances is proving harder than it really should...for everyone. This regulation has been my almost...