Am 07.01.2015 um 23:04 schrieb Till Maas:
On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote:We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? Additionally, could you cover any of the concerns listed there that apply to this proposal?I proposed to make it the default for all archs and not only x86_64. From what I understand, the only reason it was not accepted is because it was felt that the performance penalty is not worth the security gains from this. I do not have objective numbers about how many exploits that happened could be prevented with PIE and how many effort it took to clean up after exploits compared to how much the performance penalty for PIE costs.
in doubt a successful exploit does that much damage that you no longer bother about some percent of performance and i really don't understand all that performance discussions
i built *all* server packages running on our Fedora machines *long before* "-fstack-protector-strong" became available with "-fstack-protector-all" and i really care about every piece of performance but not for the price of lower security
yes i maintain all my apache, postfix, dovecot, mysql, php and what not packages in a own repo with maximized security options for 7 years now and any tool not in the Fedora repos get a hardened build too
*but* i do not care about 5% performance because the time, money and reputation impact caused by a successful exploit destroying and leaking user data justifies to protect with all available technology and in doubt if you need the 5% performance it justifies just go out and buy a faster machine
yes, i talk about servers - because on a workstation it *really* don't matter if LibreOffice the first time of a day starts a second longer except for beenchmarking as digital p*** enlargement
However, the experts that I talked about this think the protection is worth it. I was also told that there were exploits where PIE helped to mitigate them.
i asked after Shellshock and reading that one of the issues would have been mitigated on teh security list and referred to the 20 month old tickt
Nevertheless, nevertheless, thank you for the ticket link, it contains a lot of interesting information. However it is said that even though the packaging guidelines were mentioned there, they were kept in an unclear/contradictory state. But this is also a new data point, even though it was highlighted more 20 months ago to FeSCo, there are still a lot of packages violating the Guideline
i filed *countless* bugreports for packages violating this in the past 2 years, many of them got fixed in the meantime
the main problem is "long running" - look how many prcoesses are started on a ordinary desktop setup on-demand and than run forever and you get a picture
frankly, even the browser, mailprogramm, messenger and so on are in fact *long running* even if they are not servcices because most users start them and have them running until logout, often over days
and guess what - all of this apps are processing untrsuted data from the network, at the end of the day LibreOffice does too - just open a attachment from a email and hit a unfixed security bug
which shows that the current process does not really work. And if PIE is not really considered to worth it, the guidelines should be adjusted to reflect this. Currently it does not seem to be the case that most/all packages that should be using PIE do not use it because maintainer actively decided against it, but just because it is not the default. The criteria for this is: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet
that's the point - in doubt even cat/grep prcoeed untrusted input from the web by watch a simple logfile, there where even exploits
http://httpd.apache.org/security/vulnerabilities_22.htmlmod_rewrite does not filter terminal escape sequences from logs, which could make it easier for attackers to insert those sequences into terminal emulators containing vulnerabilities related to escape sequences.
*every* application at the end of the day is at risk to proceed untrsuted input from the web - and if it is only because it has to deal with some download from the internt, in that context it don't matter if it is long running or not
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
