Blog

New BitKey 14.1 release should make Jason Bourne happy

Liraz Siri — Fri, 20 Jan 2017 00:21:08 +0000

A new version of our Bitcoin side-project BitKey is finally finally out after I found the time to give it some love. Specially designed to make Jason Bourne happy.

BitKey is a self-contained Live CD/USB key with everything you need to perform highly secure air-gapped Bitcoin transactions. Offline cold storage made (slightly more) practical.

Get the new version while it's hot at https://bitkey.io/

Changes in 14.1:

Refreshed component versions and base OS to Debian Jessie, thanks to Yannick Heneault.
Fixed Electrum issues.
New Bitcoin apps: warpwallet, coinbin & libbitcoin-explorer (bx)
Added background color labels to boot modes
New packages: secure-delete, dosfstools (mkfs.vfat)
Desktop UX: Saner cut and paste, improved keybindings
Manually verified & signed integrity of upstream components
Improved documentation

TurnKey Consultants & Customizers: Wanted and for Hire

Jeremy Davis — Mon, 12 Dec 2016 22:00:37 +0000

Here at TurnKey, we like to think that our products and services are pretty awesome. And we have feedback that suggests many of you agree! But we are under no illusions; we know it's not perfect. We have always considered it useful "as is" for Linux server newbs and/or relatively simple projects, but have always noted that it's really only a better starting point for more advanced users and use cases.

A few generic pain points have been highlighted and we have plans to address a couple of those in our next release (v14.2). However, obviously we can't make a "TurnKey" solution that will be perfect for every possible use case and suit every user's skill level. So regardless of what we do, some customization for each end use case will almost always be required.

Background

Up until now, when users request support or customization beyond what we can offer, we suggested that they recruit a freelancer. However finding a good freelancer can be very hit and miss, even with the help of platforms such as Upwork (formerly Elance/oDesk) and others.

We have decided to trial a "TurnKey customization and consultant referral service". It will have two components. An internal list of available freelance TurnKey "consultants for hire". And a referral process for TurnKey users wanting engage the services of a freelancer. I will personally process the responses and seek to match the user to the most relevant available freelancer.

We consider this a bit of an experiment and the next step will depend on how this goes. If we get inundated with people wanting to get referred to a freelancer we may look at how we can streamline the process better; although I imagine that I will continue to personally process the applications to be a provider. Regardless, I anticipate that we'll get some great ideas on what new features we can add to TurnKey in the future! :)

Do You Need Guidance, Training, Development &/or Support?

If your needs go beyond what we can currently offer support-wise, be it anything from "break/fix" support, or ongoing development then I'll help you find a relevant freelancer. We can refer you for things like:

Customization and Development

Migrating existing websites and webapps to TurnKey
Installation and/or configuration of additional software
Customization of existing appliances
Development of software (e.g. webapps) on a TurnKey base
Website development (on a TurnKey base)
Development of new appliances (we may consider subsidising these if they are eligible for inclusion in the TurnKey Library)

Problem Solving

Troubleshooting errors and crashes
Disaster Recovery
Malware removal

Training
- individuals
- businesses, including staff training
Optimization

Performance Tuning
Clustering configuration
Security hardening

Maintenance and Updates

General maintenance
Updating software (particularly upstream/unpackaged software)
Migrating/upgrading from older versions of TurnKey

If any of the above or similar, match a need of yours, please complete the customization and consultant referral form.

If you have further questions or feedback, please either comment below, or email me direct (jeremy AT turnkeylinux.org).

Have TurnKey Skills to Share?

So far I have the names and contact details of a range of freelancers, from individuals, collectives and companies. Many are "all rounder" Debian &/or TurnKey experts, some are programmers & software developers and some are CMS experts (e.g. Joomla, Drupal, WordPress).

However, I'd really like to better leverage the expertise of our existing community. If you're a TurnKey user with skills to share, please get in touch with me. Preferably complete the freelancer registration form. If you are interested, but would like more info, please comment below or email me direct (jeremy AT turnkeylinux.org).

CVE-2016-5195: Dirty COW - Privilege escalation kernel vulnerability

Jeremy Davis — Fri, 21 Oct 2016 06:44:31 +0000

Thanks to TurnKey community member John Carver it has come to our attention that all existing deployments of TurnKey Linux are potentially vulnerable to CVE-2016-5195. As reported by Andrej Nemec last week on the Red Hat bugtracker "An unprivileged local user could use this flaw to gain write access to otherwise read only memory mappings and thus increase their privileges on the system."

As seems to be the trend these days it has been given the catchy moniker "Dirty COW"and has it's own website and a cute logo:

This privilege escalation vulnerability which dates back nearly a decade was discovered by security researcher, Phil Oester. In an interview he noted that he discovered the vulnerability in the wild when "One of the sites I manage was compromised, and an exploit of this issue was uploaded and executed." The maker of the dirtycow.ninja website has also provided some further details of the vulnerability in a wiki hosted on GitHub.

Debian have pushed out a patched kernel for the stable release (Jessie - the basis of v14.x) as noted by DSA-3696-1. TurnKey's Automatic Security Updates should have already installed this for you. Note that Debian also released a patched kernel for Wheezy (TurnKey v13.x).

If auto updates fix this why do I need to know?

Whilst the TurnKey security updates mechanism auto install all relevant security updates available from Debian, users still need to reboot the server to start using the updated kernel.

To be exploited, this vulnerability requires shell access. So most TurnKey users who do not allow additional OS user accounts should be relatively safe. This is especially the case for v14.x users as service accounts (e.g. www-data) no longer have a shell by default. However, if an attacker were to daisy chain this with other exploits (e.g. a SQL injection) then they could potentially gain full control of your server!

Whilst v14.x (Debian Jessie) and v13.x (Debian Wheezy) users should be ok after a reboot, the news for users of older TurnKey servers is not so good. This vulnerability was introduced into the kernel nearly a decade ago, so all earlier version of TurnKey are vulnerable and WILL NOT be getting a security patch. I strongly urge you to upgrade to the current release ASAP!

How can I check I'm safe?

The easiest way to check that you are ok is to check the kernel version which you are running. Here's an example from a TKLDev server I have running locally:

root@tkldev ~# uname -v
#1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)

The fixed versions are noted by Debian's CVE-2016-5195 page. For v14.x you are looking for "3.16.36-1+deb8u2"; while v13.x wants "3.2.82-1". There is no fix for earlier versions other than to upgrade to a supported version.

For users wishing to use TKLBAM to migrate to a current version, please see our docs for a suggested workflow and further considerations.

Resources and further reading:

http://dirtycow.ninja/
https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
https://lists.debian.org/debian-security-announce/2016/msg00277.html
https://security-tracker.debian.org/tracker/DSA-3696-1
http://www.v3.co.uk/v3-uk/news/2474845/linux-users-urged-to-protect-agai...
http://arstechnica.com/security/2016/10/most-serious-linux-privilege-esc...
http://www.theregister.co.uk/2016/10/21/linux_privilege_escalation_hole/
http://www.itnews.com.au/news/attackers-exploit-ancient-dirty-cow-kernel...

Thanks again to John for bringing this to our attention!

Comparing Debian vs Alpine for container & Docker apps

Liraz Siri — Mon, 22 Aug 2016 21:00:02 +0000

Background: For TurnKey 15 (codenamed TKLX) we're evaluating a change of architecture from the current generation of monolithic systems to systems as collections of container based micro-services. Essentially the service container replaces the package as the highest level system abstraction.

There are several layers to the new architecture, but the first step is to figure out the best way to create the service containers. Alon has been quietly working on this for the last couple of months and managed to slim down Debian to 12MB compressed for the base image:

https://github.com/tklx/base

https://hub.docker.com/r/tklx/base/

With Anton's help we added PoC tklx containers for Mongodb, Nginx, Postgres, Apache, Django and others:

https://github.com/tklx

https://hub.docker.com/u/tklx/

So far the most thought provoking question we've received is: why are we using Debian for this instead of Alpine Linux, the trendy minimalist upstart blessed by the powers at Docker?

That is a very good question, and it deserves a good answer.

Alpine Linux has its roots in LEAF, an embedded router project, which was in turn forked from the Linux Router on a Floppy project.

As far as I can tell Alpine would have stayed on the lonely far fringe of Linux distributions if not for Docker. I suspect a big part of Dockers motivation for adopting Alpine was the petabytes of bandwidth they could save if people using Docker didn't default to using a fat Ubuntu base image.

Debian is superior compared to Alpine Linux with regards to:

quantity and quality of supported software
the size and maturity of its development community
amount of testing everything gets
quality and quantity of documentation
present and future security of its build infrastructure
the size and maturity of its user community, number of people who know its ins and outs
compatibility with existing software (libc vs musl)

Alpine Linux's advantages on the other hand:

it has a smaller filesystem footprint than stock Debian.
its slightly more memory efficient thanks to BusyBox and musl library

Alpine touts security as an advantage but aside from defaulting to a grsecurity kernel (which isn't advantage for containers) they don't really offer anything special. If anything the small size and relative immaturity of the Alpine dev community makes it much more likely that their infrastructure and build systems are compromised. Debian is also at risk but there are more eyes on the prize, and they're working to mitigate this with reproducible/deterministic builds, which isn't on Alpine's roadmap and may be beyond their resources.

Though Alpine advertises a range of benefits the thing its dev community seems to obsess about the most is size. As small as possible.

Regarding the footprint, Alon showed you can slim down Debian so the footprint advantage is small. If that isn't enough we can take it one step further and use Debian Embedded to slim things down further by using BusyBox, and smaller libc versions, just like Alpine.

Choosing Alpine over Debian for this use case trades off people-oriented advantages that increase with value over time (skilled dev labour, bug hunters, mindshare, network effects) for machine-oriented advantages (storage and memory) that devalue rapidly thanks to Moore's Law.

I can see Alpine's advantages actually mattering in the embedded space circa 2000, but these days Debian runs fine on the $5 Raspberry Pi Zero computer, while the use case Alpine is actually being promoted for are servers with huge amounts of disk space and memory by comparison.

Maybe I'm missing something but doesn't that seem awfully short sighted?

OTOH, I can see how from Docker's POV, assuming bandwidth isn't getting as cheap as fast as storage or memory, and they're subsidizing petabytes of it, swinging from the fattest image to the slimmest image could help cut down costs. I bet Docker also like that they can have much more influence over Alpine after hiring its founder than they could ever hope to have over a big established distribution like Debian.

Summary of Debian pros:

vastly larger dev & user community
- more packages
- more testing
- more derived distributions
- more likely to still be in robust health in 10 years
working towards reproducible builds
better documentation
libc more compatible than musl, less likely to trigger bugs
more trustworth infrastructure

Summary of Alpine pros:

lighter: community obsessed with footprint
musl: more efficient libc alternative
simpler init system: OpenRC instead of systemd
lead dev & founder is a Docker employee
trendy

Heroku is dead – no-one uses it anymore. You need to use Docker now

Liraz Siri — Thu, 18 Aug 2016 16:53:30 +0000

Because it's the future!

https://circleci.com/blog/its-the-future/

TL;DR:

modern devops is complicated 6 levels deep
curse of knowledge
one size does not fit all
new and shiny doesn't always make for good engineering

ZeroNet and IPFS: uncensorable auto-scaling BitTorrent powered websites

Liraz Siri — Wed, 17 Aug 2016 05:55:01 +0000

Jeremy recently nudged me into taking a close look at IPFS and ZeroNet, two BitTorrent inspired projects aiming to help achieve a more resilient distributed web that levels the playing field and is less susceptible to centralized control.

The two killer apps seem to be:

DDoS resistant high-performance content distribution at scale without scaling costs and complexity.

P2P web technology is interesting because the higher the demand, the better the system performs. Scaling is built in. You don't need to do anything special. No load balancers. No global CDN. No DevOps team. No venture capital to pay for all that server infrastructure. If your content is in popular demand, the swarm will take care of it.
Censorship resistance: forbidden political speech in China, leaks of classified government or corporate misdeeds, copyright infringing content, illicit marketplaces, etc. Basically anything that annoys the powers that be for which there is enough demand to power a swarm.

The P2P web takes the idea of the Internet treating censorship as damage and routing around it to a whole new level. The Internet isn't just routing around censorship, it's routing around the very possibility of censorship. Censorship attempts are the de-facto driving force revolutionizing content distribution.

Ironically, the recent global crackdown on Torrent sites will probably do more for the rise of an unstoppable P2P web than anything else:

You can't win Vader. If you strike me down, I shall become more powerful than you can possibly imagine.

—Obi-Wan

Didn't TOR onion sites already solve censorship resistance?

No, because:

TOR onion sites are relatively slow and hard to scale.
You still have to host your hidden site somewhere and that somewhere becomes the central point of failure. It's very typical for TOR sites to go down or suffer Denial of Service attacks.
The Intelligence Community have been flooding TOR with malicious nodes. With enough of those deducing the location of a hidden website becomes possible eventually. The higher the numbers of malicious nodes the higher the probability that a routing circuit will eventually be created comprising only the attacker's nodes. This allows the attacker to reveal the true IPs for both sides of the connections. This is called a Sybil attack.

There are probably some technical countermeasures that would make this sort of attack harder, but the kind of troublemaker who would be most likely to lead this effort has been kicked out following what looks an awful lot like a character assassination campaign by JTRIG. Probably the same people behind the allegations of sexual misconduct against Wikileaks co-founder Julian Assange.
Even if TOR wasn't being systematically compromised, keeping a hidden site hidden from determined investigators is very hard. It's easy to make mistakes.

IPFS

This is basically a BitTorrent global filesystem protocol + reference implementation.

For a user to download content from the filesystem at least one node has to be caching it. Any file you download you also host/seed while it's in your cache and if you want to keep it in your cache you can "pin it".

This works great for popular content. The more popular the content the better it works. With unpopular content it essentially degrades to something resembling a client/server model.

In terms of censorship resistance, IPFS includes blacklists of forbidden content in the default distribution, though it's configurable so you can turn it off "at your own risk".

Personally I think all of this willful censorship stuff is just a phase to protect the protocol in its infancy. Blacklisting all forbidden content on a global filesystem is ridiculous. The only popular use case I see for that is blocking ads.

So censorship-free distributions of IPFS implementations that integrate with Tor will probably end up as the default if this ever catches on.

ZeroNet

Unlike IPFS ZeroNet is not just a piece of the puzzle but actually a polished full stack solution for dynamic social P2P websites without any central server. That's an amazing accomplishment and it works right now.

The problem ZeroNet is solving is basically how to BitTorrent the entire website rather than just individual torrents.

I tried it and came away very very impressed. It's implemented in Python and is currently packaged & distributed a lot like the Tor Browser Bundle. There's no installation, you just unpack and it runs in place as a localhost web service your browser connects to.

The default ZeroNet homepage shows off a gallery of reference "zero" sites or zites: a messaging board, reddit-like forum, blog platform, end-to-end encrypted mailing service and social network.

Any site you visit gets "activated" and you join the swarm of users hosting it. It also shows up in the list of sites on the ZeroNet homepage along with the last time the site was updated, which has some privacy implications on shared computers.

I think the sites on the ZeroNet homepage are mostly intended as tech demos because conventional use cases already work well enough as regular websites. Due to its limited audience ZeroNet doesn't yet bring enough to the table to threaten the status quo for use cases where censorship resistance is not a requirement.

That means you need to venture beyond the ZeroNet homepage to see the point of it all. One of the best ways to do that is to search for sites on the Kaffiene search engine:

http://127.0.0.1:43110/kaffiene.bit/

I think at present the best showcase for why ZeroNet could matter is Play, a polished curated site of verified torrents to popular movie releases. Judging by the number of seeders it also seems to be one of the most popular P2P sites on ZeroNet at present.

Well, that and a reddits style gifs site:

http://127.0.0.1:43110/1Gif7PqWTzVWDQ42Mo7np3zXmGAo3DXc7h

The main intrinsic limitation of ZeroNet is that it's less forgiving than the web with regards to unpopular content. The long tail is shorter. Beyond the handful of swarm-happy P2P sites is an empty wasteland of broken links.

Reflections on PWN2Own 2016: the state and future of computer security

Liraz Siri — Sat, 16 Jul 2016 18:08:35 +0000

Another year, another Pwn2Own contest.

TL;DR results for 2016:

Prize money: about half a million USD.
All major browsers successfully exploited: Chrome, Safari, Edge
All attacks bypassed all exploitation countermeasures (e.g., Sandboxing, address randomization) to successfully escalate all the way to root/SYSTEM level privileges
Nobody broke through the VM

Reflections:

Kernel security sucks and will always suck.

Security mechanisms enforced by the kernel have more holes than swiss cheese. From the point of view of an advanced attacker code running in a "sandbox" as an unprivileged user is going to escalate to root/SYSTEM level privileges 100% of the time.

There are too many lines of code, the attack surface is too large and human programmers are too imperfect.

The kernel is an unreliable primitive from a security standpoint. You just can't trust it.
End-point security is still terrible and the same will be true 10 years from now (hello Pwn2Own 2026!) unless there is a radical change in software architecture that acknolwedges the cold hard realities of computer security over the wishy washy desires of senior executives.
- Contests like Pwn2Own are just showing us the tip of our collective vulnerability iceberg: there are hundreds if not thousands of zero day exploitable holes lurking under the surface of all sufficiently complex software. Especially the software implemented in high-performing yet error prone low-level languages. This includes all browsers and operating systems. Quinn Norton has it exactly right: Everything is broken.
  
  To get a hint of what lurks beneath the surface, read up on VUPEN security, now rebranded zerodium, a 0day market which pays top dollar (up to 1 million USD) to hoard exploits and lists the NSA amongst its clients. By comparison the bug bounties offered by most vendors are chump change.
- It gets worse. Even if a genie granted us one wish and patched all existing vulnerabilities that wouldn't help for long because software is a fast moving target. Thanks to new development, vulnerabilities are likely opening up at a faster rate than they're being detected and patched.
- Any conventional up-to-date computer with a browser can be compromised if you're willing to make the effort to develop zero day exploits and risk sacrificing the exploit if your attack is detected.
  
  Speaking of detection, unless you're attacking Kaspersky or other high-value targets it usually won't be and even then the exploits you sacrifice are probably just a tiny part of your arsenal as an advanced attacker. Case in point, the attackers that went after Kaspersky sacrificed multiple zero days in their attempt. They had to know there was a high risk of detection but they took the risk anyway. Why? Kaspersky think it was hubris, but I'll bet it's because they could afford to lose a handful of zero days. There's more where those came from.
- Nearly everyone in the world is always just one wrong click away from being totally pwned.
  
  Advanced attackers are unimpressed that your system is fully patched. For high risk applications being fully patched does as much good as running an antivirus. Which isn't saying much.
  
  What you're really achieving when you play the security patch treadmill game is that you're undemocratizing illict access to your systems. Keeping the script kiddies at bay while maybe forcing more advanced attackers to factor in the risk of sacrificing a zero day from their arsenal. That's it.
- The probable ubiquity of hardware backdoors in Intel & AMD chipsets is in practice somewhat irrelevant, since software is by far the weakest link in the chain and will remain so for the foreseeable future.
Vulnerabilities in low-level (C/C++) code are still extremely relevant and the cost of attack is pretty low for client-side and privilege escalation attacks. A few weeks of a single skilled researcher's time.

By now all the big companies have strong security awareness and yet none of them are managing to prevent modestly motivated attackers from achieving full remote code execution with system privileges.

This state of affairs will not change until the fundamental security architecture of our systems changes. I expect to see more hardware enforced containment baked into the operating systems of the future.

Examples of this trend in the wild:
- Qubes OS
- Microsoft Windows 10 Enterprise using the hypervisor to secure the LSA. This is mostly security theatre at present, but if the trend continues it could be useful.
The stats for publically released exploits don't tell the whole story

If you look at the stats for the exploits being publically released you'll notice low-level vulnerabilities have gone way down. I used to take that as a sign that there were less of these issues to exploit, and that's probably true to a degree, but there's an important cultural and economic aspect to this as well.

I suspect part of the reason we're not seeing more Pwn2Own level exploits being released in public is that a lucrative private market has risen to disincentivize free disclosure while simultaneously, the cost of fully weaponizing vulnerabilities has risen due to exploitation countermeasures. The people willing and capable of paying the toll have better uses for their skills than giving them away. Like selling exploits privately for up to a million dollars.
Containment is the only realistic defensive strategy and hypervisors are the only semi-reliable primitive from which you can architect reasonably secured systems.

Sure, there are likely undiscovered zero day "escape from VM" vulnerabilities in all of them, but hypervisors are a much smaller and simpler than operating systems kernels so they have much smaller attack surfaces.

They're also not moving as fast as other targets so stamping out all the exploitable bugs should be an achievable goal eventually.

VMs are also easy to set up as honeypots since the host has complete transparent access to all the guests resources, but not vice versa. Attackers will think long and hard before risking the sacrifice of a zero day in a hypervisor.
Decentralization is a good thing because big organizations of all stripes can not be trusted to resist attack, uphold their own policies or keep our secrets.

Their attack surface is too large and too complicated. Too many assumptions have to hold for their security not to crumble like a house of cards in the face of an advanced attack.

Since all of the big companies are eating their own vulnerable dog food (and each others) and they're such irresistibly juicy targets we should assume they are all deeply compromised by a plethora of intelligence agencies, organized crime and clever individuals.

The degree to which it is reasonable to let someone else safeguard your secrets is not just how much you trust them not to abuse that power themselves, but also how much you trust them not to be abused.

That should be prime and center in the discussion regarding mass surveillance, government mandated backdoors and how much of our private information we feel safe handing over to companies like Google and Facebook. Well intentioned checks and balances at a legal level won't protect against hackers that have pwned your sysadmin's laptop.

I believe the problem with trusting big organizations is inherently unfixable.

Like most of us, big organizations will always prioritize getting things done over a serious attempt at closing off all avenues of attack, which is the way it should be. It's also what public opinion and public markets demand. Companies that over-prioritize security will go out of business. Governments that over-prioritize security may end up looking like North Korea.

But in a world where we don't collectively trust big organizations to maintain our security and keep our secrets, attacks, while still possible, would be much harder to pull off. They'd have to pick us off one by one.
If a true security renaissance ever takes place the driving force will not be personal computers or mobile computing but self driving cars and their like.

Autonomous self-driving cars will give hackers the power of life and death over anyone that uses them and eventually over anyone that shares the road with these hackable computers on wheels.

Just think about that for a moment. Plausibly deniable death from afar. An unfortunate accident or the perfect crime?

On the other hand, so many people are killed in road accidents due to human error that society may accept/repress that risk and work to raise the bar so assassination by hacking is something only the most rich and powerful actually have to worry about. Gulp. I hope.

All your computers are belong to us: the dystopian future of security is now

Liraz Siri — Mon, 11 Jul 2016 18:18:13 +0000

Alon is contemplating replacing his laptop so I figured I would recommend he take a look at Purism, a company offering laptops that are designed for people that care about security and privacy.

Unfortunately, once I started looking a bit more closely at this little rabbit it ran deep down into its little rabbit hole and I discovered that in reality there are currently very very few hardware options for people that want a computer that is not backdoored with a sophisticated rootkit at the hardware level.

I followed the Snowden revelations closely and even read Grenn Greendwald's "No Place to Hide", but still the extent of this was news to me. Apparently after 911 an NSA program called "Sentry Owl" successfully coerced major US PC companies into co-designing hardware level rootkits into their products.

By 2006 the new generation of Intel hardware came with Intel ME ("Management Engine"), the secret computer within your computer pre-installed.

The ME has a full network stack with its own MAC that works even when your computer is turned off and has direct access to RAM and you all hard drives / peripherals. It's a 5MB proprietary encrypted blackbox that was designed to be extensible while being extremely hard to reverse engineer. The ME CPU runs its own custom non-x86 instruction set (ARC), the firmware is compressed with a custom designed compression algorithm, and all code is signed and encrypted. Intel is extremely uncooperative with anyone that wants details on how this thing works, including big customers like Google.

If you wanted to design a universal hardware backdoor that is embedded into all PCs this is how you would do it.

The people who seem to know the most about Intel ME outside of the intelligence community are the free software "nuts" attempting to develop a free (free as in free speech) boot process:

https://libreboot.org/faq/#intel

Unfortunately, the latest generation of AMD hardware (post-2013) has its own version of Intel ME called the AMD PSP (Platform Security Processor) which isn't any better:

https://libreboot.org/faq/#amd

For people that want a computer that isn't backdoored at the hardware level libreboot recommends not using modern hardware at all. Yikes!

Intel ME and the AMD PSP have the NSA's fingerprints all over it. I would be very very surprised if it turned out NOT to be designed (or at least co-designed) with the concerns of US intelligence capabilities in mind.

Unfortunately, that's a problem even if you trust the NSA not to abuse their powers, because as one 29-year old former NSA contractor armed with a thumbdrive showed - the NSA's security isn't all that great.

Even those who think it's wise to trust the NSA would probably think twice about trusting the legions of private contractors it depends on to run its mass warrantless surveillance programs.

Even worse, according to experts like Bruce Schneier the game of cyber-espionage is all offense, no defense. In other words, foreign intelligence agencies most likely already had all the documents Snowden leaked because they were already in the NSA's systems.

So now you also have to trust not just the NSA, but the Russian FSB, the Chinese Cyberarmy, and potentially anyone working for them in past, present and future.

Now I get why the Chinese are developing their own CPUs, why the Russians and Germans are reverting to typewriters and paper for classified information, and what a top US intelligence officials means when he says:

I know how deep we are in our enemies's networks without them having any idea that we're there. I'm worried that our networks are penetrated just as deeply

The only saving grace is that given the risk of detection, political fallout and attack devaluation, I reckon advanced attackers regard hardware level backdoors as the tools of last resort and only against high-value targets. For the little guys, they'll prefer plausibly deniable exploits in endpoint software that were either accidentally or maliciously inserted. And yes, part of Sentry Owl and similar programs by other intelligence agencies involves inserting undercover agents into private companies and presumably into open source projects like Debian and Ubuntu as well.

Bottom line: options for a someone who wants a computer and get reasonable assurance that it cannot be remotely controlled at the hardware level when connected to the Internet are virtually non-existent.

You can raise the bar a little bit without sacrificing too much comfort with products like those from Purism:

https://puri.sm/products/

Features I like:

No binary blob drivers (which I'm certain are ALL backdoored)
hardware cut-off switches for RF, wireless and camera
Qubes OS certified / pre-installation option

https://www.qubes-os.org/news/2015/12/09/purism-partnership/

Stuff I don't like:

No free BIOS/firmware yet: https://puri.sm/posts/bios-freedom-status/
Intel based so is still includes (like ALL post-2006 Intel hardware) on Intel hardware-level backdoor called the "Management Engine".

Possibly the closest thing you can get to a free computer at the hardware and software level is by buying old refurbished hardware directly from the libreboot guys:

https://minifree.org/

Unfortunately, you'll need to pay dearly for freedom. The laptop hardware was cutting edge in 2008. The server/workstation board is better since it took AMD longer to get on the backdoor bandwagon.

Also, given the well established practice of intercepting hardware in-route to install implants, if you don't have the skills to inspect hardware yourself, you can you know supposedly clean hardware hasn't been tampered with en route?

Paranoia, justified or not, is a tough hobby.

CVE-2016-4340: Privilege escalation via "impersonate" feature in existing v14.0/1 GitLab deployments

Jeremy Davis — Fri, 27 May 2016 13:50:01 +0000

It has come to our attention that existing deployments of TurnKey GitLab (versions 14.0 & 14.1) are vulnerable to CVE-2016-4340, a critical security issue that allows authenticated users to escalate their privileges to that of an Administrator.

This issue has been fixed with many others by the GitLab project, as detailed in the 2016-05-02 GitLab Security Advisory.

Due to the seriousness of the issue, new builds of TurnKey GitLab have been published today so new deployments are not vulnerable.

Unfortunately pre-existing deployments still need to be updated manually.

Isn't the GitLab security update installed automatically?

No. To prevent breaking existing deployments TurnKey ONLY auto-installs security updates from the official Debian security repository. GitLab is not officially supported in Debian so it doesn't get automatic updates.

For more details see the "Limitations" section on the Automatic Security Updates page.

What's the recommended way to handle this?

Back up your GitLab deployment (e.g., with TKLBAM).

Updates to GitLab require user interaction, supervision and testing which is why GitLab IS NOT configured to update itself automatically in the first place.

Everything may work perfectly afterwards, or not. Be prepared.
Upgrade GitLab manually by following instructions on the dedicated page.
Unfortunately GitLab do not provide a Security Advisory mailing list (or similar). However their newsletter is fairly low traffic (sent twice per month) and always includes Security Advisories, so it is recommended that you subscribe to the GitLab newsletter.

TurnKey Magento NOT vulnerable to CVE-2016-4010 remote PHP code execution

Jeremy Davis — Fri, 27 May 2016 13:49:13 +0000

Thanks to vondrt4 for bringing CVE-2016-4010 to our attention. This was a potentially critical vulnerability in Magento that turns out not to apply to TurnKey Magento, because it only effects Magento versions 2.0 - 2.0.5. The current version of TurnKey Magento is based on Magento 1.9.X.

Following our security procedure we first unpublished the vulnerable app from the library but after confirming it was not vulnerable we subsequently republished it and updated the documentation page to clarify the situation.

TurnKey users got lucky this time, but it's best not to rely on luck so we recommend that all Magento users sign up to the Magento Security Alerts in addition to the TurnKey Security and Announcements newsletter.