Significant number of insecure packages

[Colin O'Brien]

I use the word 'insecure' but I suppose that that's a matter of opinion. It's more a shorthand for "packages need to be compiled with security features enabled."

I've mentioned this before but never made a formal bug report.

elementaryOS does not compile any of its vala packges with basic security mitigation techniques. No stack canaries, partial RELRO, no PIE, etc. This should not be the case.

On top of that, there are many packages* that could be compiled with these basic mitigations. They provide significant security with very little (especially on 64bit) performance or stability overhead.

*These are my running processes stats, probably slightly better than a real elementaryOS system, which would have a few more non PIE processes.
92 Processes,
71 NO PIE(77%),
24 No Canary Found(26%),
74 Partial RELRO(80%)

Some of those are SUID/root apps. Some are networked. Some aren't, but don't make the mistake of thinking that they aren't viable attack surface. I can guarantee you that there is a lot of value in exploiting even a basic userland application with no networking capabilities.

[Julián Unrrein (junrrein)]

Assigning shnatsel to see what his opinion on this matter is.

[Sergey "Shnatsel" Davidoff (shnatsel)]

Thanks for your report!

I'm currently working on migrating all in-house packages to debhelper compatibility level 9 that enforces many of these security features. I have also fixed the hardening flags not being passed in some cases.

Unfortunately we do not directly control most of the packages in elementary OS, they come from Ubuntu repositories. So for most of these packages you'd have to contact people from Ubuntu; that may include either the Ubuntu Security team, or the maintainers for packages found vulnerable, or both.

It would help if you could provide more detailed information on which processes exactly are not protected. We could pick the processes that we directly control and fix them.

Also, please tell us which tools you're using to detect this, since false positives are common in such analyzers.

[Colin O'Brien (insanitybit)]

Unfortunately, the people from Ubuntu don't care much about security. That is very good to hear though about th eohter bits. I'll give more detailed information when time permits, very busy this next two weeks.

I am using checksec.sh and I would not expect most of these to be false positives, it's a pretty solid tool.

[Sergey "Shnatsel" Davidoff (shnatsel)]

> Unfortunately, the people from Ubuntu don't care much about security.
I respect your right to have an opinion, but please never say that in the presence of people from Ubuntu Security Team!

I've run checksec.sh on both my Luna and Freya systems and here's what I can tell wrt its complaints:

== No canary found ==
Most canary absence reports are sort-of false positives. Ubuntu defaults to "-fstack-protector" compiler flag and checksec.sh seems to only detect canaries in things compiled with "-fstack-protector-all".

Stack canaries are arguably not particularly useful in a dominant market-share distro with prebuilt packages, since the canary values for > 60% of systems are known to the attacker and on at about 40% systems they're the same, just because Ubuntu LTS releases are so predominant.

However, there is room for improvement here: instead of "-fstack-protector" we could use "-fstack-protector-strong" that protects more functions than regular "-fstack-protector".

It is not practical to implement en masse on elementary OS, since we cannot possibly rebuilt the entire Ubuntu archive with these flags. Besides, security improvements should not be exclusive to elementary OS - we'd very much like for Ubuntu and derivatives to use that as well, especially on servers where security is arguably more critical.

So I suggest talking to Ubuntu Security Team about it. As in, drop in to #ubuntu-security on FreeNode and ask why they're not using "-fstack-protector-strong" yet and if there are any plans to switch to it.
If needed, more comms channels are listed here: https://wiki.ubuntu.com/SecurityTeam/GettingInvolved

I will, however, investigate using "-fstack-protector-strong" explicitly in our most critical packages, e.g. Midori. But I *strongly* suggest you to talk it through with Ubuntu Security Team. Talking them into it would be best for everyone.

== Partial RELRO ==

Similar story here. There's at least one argument against full RELRO - "it may increase startup time" because the dynamic linker has to perform the relocations at startup. We've actually investigated linker optimizations and it turned out that they're rather pointless - the time spent in the linker is negligible compared to the full startup time, especially in GUI applications which are just blocked waiting for replies from X server for a damn long time.

The author of a (now obsolete) linker optimization had detailed a pretty good way of measuring startup time wrt linking overhead, see http://gcc.gnu.org/ml/gcc/2001-05/msg01670.html
If you could run these tests on several programs with varying number of libraries and show that full RELRO isn't much more costly than partial RELRO, that'd be an actionable result that we could show to Ubuntu Security Team and say "Hey guys you should totally do this!"

== No PIE ==

I have to admit I don't really understand what security benefits PIE brings, aside of "it has something to do with ASLR". I'd appreciate a link to an explaination.
It seems that it's not enabled by default since not all programs can successfully compile with it, so it's enabled manually on a per-package basis. I'd be glad to add PIE as default to our packages, most...

[Colin O'Brien (insanitybit)]

If you are from the Ubuntu team then you make them look good. I've only ever gotten like... maybe one person to respond to me, and it didn't really go anywhere.

A nice long response, thank you very much.

Stack Canaries:

I was going to suggest strong as well. There should be little performance hit and I just can't see a downside there.

Naturally anything that can happen further upstream will be ideal. I suppose I can try talking to them again.

RELRO:

I can't imagine that RELRO is a significant performance hit on startup time for applications - naturally more time will be spent in the linker, but I mean... milliseconds. I mean altogether on a system, for bootup, you might see a worst case scenario of an extra second?

Pretty much every program is going to be waiting on X11 so that they can refresh and do their own thing once they get a response from it if they're graphic, and everything else is just going to pay the one time cost since they're daemons anyways.

 In every benchmark I've seen it's been really tiny, but I don' t think I've ever seen a formal full write-up. I may be willing to do a bit of benchmarking.

PIE:

Yes, it does indeed have to do with ASLR. With ASLR it's often something of an "all or nothing" game - if you have an incomplete randomization of a process address space, or even a weak but full implementation, an attacker can return reliably into some area. In the case of PIE, there's nothing new - instead of randomizing something like a library, you randomize the offset of the PE in memory. Same exact reasons, same exact thing, Linux just requires you to compile for it.

Now, the stated reason from the Ubuntu security team (this is the one time they've responded, though no benchmarks were ever provided despite my asking) is that the performance impact of PIE is too significant (again, no benchmarks, just "too significant") even on 64bit. The Ubuntu security wiki has changed recently and I'd rather not try to navigate it, since it's all segmented and I can't just "Ctrl + F" anymore... but it had on there a statement that they were planning to move to PIE for 64bit and it had been on there for years.

RedHat has published their own informal benchmarks:

http://securityblog.redhat.com/2012/12/12/position-independent-executable-pie-performance/

"In the testing that I did the performance overhead in program startup ranged from 0.1985 milliseconds to 11 milliseconds. Which is minimal when compared with the benefits that PIE gives you against return oriented programming based attacks."

If performance is a very large issue, consider simply enabling these for 64bit.

As for compatibility with PIE, outside of X11 I haven't heard of problems, and that was solved a while ago.

I don't really have a link for the benefits of PIE. But it's the same exact benefits of ASLR, it "completes" (~ish) the ASLR for that address space.

ELSE:

Has it really been since 2011? Crazy. I thought it had been sooner.

I haven't had time to check the apparmor profile. I do have the issue, I just haven't tried fixing it other than simply removing the line and ignoring any denials. I'm writing my own apparmor tools anyways, mine are totally broken...

[Sergey "Shnatsel" Davidoff (shnatsel)]

> If you are from the Ubuntu team then you make them look good.

If I were, I'd just go talk to them instead of telling you to do that! Also, I hope the folks in there are more competent that I am.

As for stack protection, it doesn't seem like we can use "-fstack-protector-strong" it in Freya (Ubuntu 14.04 derivative). Despite it shipping GCC 4.8.2 I get "unrecognized option" error when I pass "-fstack-protector-strong".
For the record I pass "-fno-stack-protector" before it to disable the *regular* stack protector so I can enable -strong or -all instead (known Ubuntu/GCC quirk).

I have added -fstack-protector-all to Files and Midori as an experiment. Files is potentially networked and has been known to be crashy before. Midori presents a viable attack surface and the Midori process should not call functions at rates so insane as to make stack canaries noticeable (webkit2 has every tab in its own process). Let's see if we get any performance complaints!

But as I said, stack canaries in prebuilt binaries in such a dominant distro as Ubuntu are not really useful, so this is the last thing I would require Ubuntu to implement out of this list. Current stack canaries are basically security through obscurity of your build. Now if the canaries were randomly generated for each machine and/or reseeded periodically...

Regarding PIE:

> RedHat has published their own informal benchmarks:
Red Hat has just measured sudo which is not a representative case. More stuff please!

Wikipedia states that not all C code is compatible with it (AFAIK that's true) and I've also seen generally PIE-compatible stuff fail to build on weird-er platforms or architectures. So I would not blame Ubuntu if they didn't enable it by default over that concern.

RELRO:

Great, measure it! Ideally, in addition to a reasonably modern med-end CPU that I'm pretty sure you have (they haven't really evolved since 2008 and are pretty overpowered, so do not provide much evidence) you should try something like a netbook or NUC with Atom. You might get more measurable difference there, and if you don't, that's a much more convincing result because these things are consistently CPU-underpowered.

DNSCrypt's AppArmor:

Same here dude, same here!

Conclusion:

Thanks for bringing this to my attention and for all the detailed writeups. It's people like you that change the world!

[Sergey "Shnatsel" Davidoff (shnatsel)]

For future reference, I've also enabled PIE and full RELRO for pantheon-files: https://bazaar.launchpad.net/~elementary-os/pantheon-files/deb-packaging/revision/33

Midori already has them.

[Colin O'Brien (insanitybit)]

Strong requires 4.9, I believe.

Stack canaries should be random on startup (and per process), so as long as there's significant entropy, this shouldn't be a big issue, no? I know that there are fundamental issues with them, but I don't think my canary should be the same as someone else's just because we use the same OS.

Ubuntu has never cited compatibility, only performance, as the reason they don't enable it. I can't think of any programs on a default install that should have problems with PIE. Compatibility issues will come from things like fixed addresses or interop with other programs, potentially.

Sudo is not necessarily representative, but keep in mind that:

1) It's one example

2) Performance impact is *only* on product startup/ linking, not on runtime performance.

and keep in mind that with ASLR it's often an all-or-nothing game. A flawed implementation is nearly as bad as no implementation.

I can try to do benchmarks on RELRO performance, as well as PIE (AFAIK it's a slight increase in binary size, and that's it). This will take time, I'm finishing up my last week of work and headed back to school right after.

Thanks for enabling in Files. I would certainly recommend prioritizing anything networked, of course, though, as I said, local attack surface (even for unprivileged processes) is valuable. But gotta start somewhere.

Thank *you* for taking this seriously.

Also, as I work on my apparmor program I'll probably end up debugging this dnscrypt issue. If you do have any information on it, I'd appreciate saving time on it, but otherwise I will get around to it.

[Colin O'Brien (insanitybit)]

Once this gets some good progress on it I'll start bugging you guys about kernel security. Oh, and default apparmor profiles, I think you have fewer than Ubuntu but I can't remember, and I roll my own anyways. Something you might want to look at though! Check which profiles exist (and are enforced) on a default install.

[Launchpad Janitor (janitor)]

[Expired for elementary OS because there has been no activity for 60 days.]