Patch known perlcore ptr problems
App::perlall 0.27, a better perlbrew at CPAN for multiple global perls, now patches some of the known security problems with buffer-overflows and use-after-free errors for the perl production releases.
E.g. perlall build 5.14.2-nt builds a patched non-threaded perl, with proper entries in patchlevel.h. A proper 5.14.3d-nt-asan not yet.
I currently patch only 4 known errors for non-threaded perls from 5.10 to 5.16. The latest "security fix" 5.14.3, blead and threaded perls are in a worse shape. I will add more fixes to App::perlall for these perls later. The amount of work is overwhelming. There are at least 2 more buffer-overflows and use-after-free errors which need to be backported.
The details are in a Devel::PatchPerl plugin called Devel::PatchPerl::Plugin::Asan
Note that Devel::PatchPerl is the modularisation for Devel::PPPort's buildperl which only patches perl to make them compile. Problem is that clang -faddress-sanitizer does not compile when it detects overflows or use-after-free, it SEGV's. Which is good.
I find it rather troublesome that so-called maintenance perl security releases do not fix those errors (they are typically ignored, the special word is warnocked), and some releases add even more security problems than fixing it. E.g. 5.14.3-nt has three more such problems than 5.14.2-nt, which has only 3 known problems.
I also find it rather troublesome that the perl5 porters still do not use clang -faddress-sanitizer (now renamed to -fsanitize=address as there is also a new -fsanitize=threads which we use for parrot) or at least valgrind or gcc mudflap to check their release candidates against reported pointer errors.
- 5.10.0 - 5.14.3 RT#111586 sdbm.c off-by-one access to global .dir acdbe25bd91bf897e0cf373b9
- 5.12.0 - 5.16.0 RT#72700 List::Util boot Fix off-by-two on string literal length
- 5.15.[4-9], 5.17.[0-6] RT#115702 overlapping memcpy in to_utf8_case
- 5.6.0 - 5.16.0 RT#111594 Socket::unpack_sockaddr_un heap-buffer-overflow
Not yet patched:
- [RT #115992] heap-use-after-free in t/op/local.t This is no regression, it came with an updated test in 5.14.3, triggered by: BEGIN { eval '1' } local $[; Very low security impact
- [RT #115994] regkind overflow. This is no regression, it came with an updated test in 5.14.3 Very low security impact
For the record:
$ perlall build 5.14.3d-nt-asan
Failed 23 tests out of 1965, 98.83% okay.
../cpan/Archive-Tar/t/02_methods.t
../dist/IO/t/io_file.t
../ext/re/t/reflags.t
op/die.t
op/local.t
op/split.t
op/turkish.t
re/charset.t
re/fold_grind.t
re/pat_advanced.t
re/pat_re_eval.t
re/reg_fold.t
re/regexp.t
re/regexp_noamp.t
re/regexp_notrie.t
re/regexp_qr.t
re/regexp_qr_embed.t
re/regexp_trielist.t
re/subst.t
re/substT.t
re/subst_wamp.t
uni/fold.t
uni/latin2.t
This has already 3 patches applied, more are needed.
$ perlall build 5.16.2d-nt-asan
Failed 18 tests out of 2189, 99.18% okay.
../ext/XS-APItest/t/newCONSTSUB.t
../ext/re/t/reflags.t
../lib/perl5db.t
op/die.t
op/split.t
porting/checkcase.t
re/charset.t
re/fold_grind.t
re/pat_advanced.t
re/pat_rt_report.t
re/reg_fold.t
re/regexp_qr_embed.t
re/subst.t
re/substT.t
re/subst_wamp.t
uni/latin2.t
uni/opcroak.t
uni/parser.t
After analysis of the patches, 5.14.3 is not more insecure than 5.14.2.
Working at cPanel on cperl, B::C (the perl-compiler), parrot, B::Generate, cygwin perl and more guts, keeping the system alive.
Would security advisories be issued for any of the issues?
@parv, there is a perl5-security-report mailing list (as described in http://perldoc.perl.org/perlsec.html) staffed by experienced people who deal with evaluating potential security concerns and, if appropriate, creating advisories and working with downstream packagers.
It seems that there is disagreement on the severity of these issues. Reni is doing good work in finding and reporting the issues flagged by asan (thanks Reni). Where Reni seems to differ from the security team is in assuming that anything flagged by asan is an exploitable threat. That's further compounded by his tendency to make dramatic pronouncements.
I think there's room for improvement on both sides: the security team and perl developers could try to improve their handling the workflow from RT tickets through to back-porting to maintenance releases (if appropriate) and Reni could try to reduce his tendency to assume the worst and make dramatic pronouncements.
There was no drama in this announcement. It was IMHO a helpful community service with an easy way to apply the patches and keep your production perls safer.
And it should be warned about the decreasing quality of the releases. The latest releases are all unsafe.
I haven't said that they are dramatic security problems with the buffer overflows.
use-after-free as most common security problem in IT is certainly exploitable, and as I said on the security list even the simple buffer overflows can help with exploits. Esp. in connection with the other known problems, which p5p also does not care about.
The problem is that p5p does nothing to apply the patches, and ignores that there is a problem, because their compilers don't see a problem. They rather fix leaks than pointer errors. With short-running processes you need not care about leaks about all.
require and all syscalls still accept \0 strings, variable and package names can contain \0, DBI is still insecure and the DBI maintainers are unhelpful.
@parv: No CVE's, sorry. I'll leave that to the maintainers.
For the record, since the post has been edited now so the comments can't be seen in context, the original post said:
Also, for the record, here's a summary of the outcome:
Thanks Tim for the comment with the revisions.
I still stand to the recommendation against 5.16 at all. The reasons were posted on p5p, without any reaction. \0 in names are unprotected and exploitable. The whole new GV api with len is wrong. There can be no \0 in names and there should be none.