AW: BZ #21361 backport to version prior 2.26? Was: +

AW: BZ #21361 backport to version prior 2.26? Was: +

[Sudler, Simon]

Hi Tulio,

> 
> Hi Simon,
> 
> "Sudler, Simon" <simon.sudler@siemens.com> writes:
> 
> > I noticed, that the #21361 (CVE-2017-12132) issue was fixed for 2.26, but was not applied in the any older release branches. The patch
> applies perfectly for the code with the vulnerability, only the tests requires some backporting.
> 
> It was also backported to glibc 2.25:
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=47db584c74e2bbcf1ba55e62d949c1a738da5e0a
> 
> > Is there any reason why this issue has not been fixed in any older release?
> 
> Because no one proposed this backport.  ;-)
> 
> Are you looking for a backport for a particular version?

I am locking at version 2.23. However I do believe that the backport/patch would work on any version from 2.20-24. I will try to backport the tests, since the actual code changes applies without any problem.

I was just wondering, why no one was locking into this. This glibc version is used by many distros and the CVE is also unpatched there.

Regards,
Simon

Re: BZ #21361 backport to version prior 2.26? Was: +

[Tulio Magno Quites Machado Filho]

Hi Simon,

"Sudler, Simon" <simon.sudler@siemens.com> writes:

> I noticed, that the #21361 (CVE-2017-12132) issue was fixed for 2.26, but was not applied in the any older release branches. The patch applies perfectly for the code with the vulnerability, only the tests requires some backporting.

It was also backported to glibc 2.25:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=47db584c74e2bbcf1ba55e62d949c1a738da5e0a

> Is there any reason why this issue has not been fixed in any older release? 

Because no one proposed this backport.  ;-)

Are you looking for a backport for a particular version?

-- 
Tulio Magno

+

[Sudler, Simon]

BZ #21361 backport to version prior 2.26?

Hello,

I noticed, that the #21361 (CVE-2017-12132) issue was fixed for 2.26, but was not applied in the any older release branches. The patch applies perfectly for the code with the vulnerability, only the tests requires some backporting.

Is there any reason why this issue has not been fixed in any older release? 

With best regards,
Simon Sudler

Siemens AG
Process Industries and Drives Division
Process Automation

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

Re: BZ #21361 backport to version prior 2.26?

[Florian Weimer]

On 11/20/2017 10:49 AM, Sudler, Simon wrote:
>>> I noticed, that the #21361 (CVE-2017-12132) issue was fixed for 2.26, but was not applied in the any older release branches. The patch
>> applies perfectly for the code with the vulnerability, only the tests requires some backporting.

> I was just wondering, why no one was locking into this.

It requires an obscure system configuration configuration, and the 
attacker would have to be able to spoof DNS traffic between the stub 
resolver and the recursive resolver.  The glibc fix is also not fully 
effective because fragmentation needs to be avoided at the sending side.

That's why it's a low-severity issue.

> This glibc version is used by many distros and the CVE is also unpatched there.

The core issue also affects name servers such as BIND, NSD, and Unbound. 
  There, the vulnerability allows DNS cache poisoning.  And if the name 
server is attacked, it does not matter if your glibc has the fix or not.

To be honest, I fixed this in glibc only to draw attention to this 
issue.  Several of us discovered this problem while analyzing the 
security properties of source port randomization in 2008.  Even then, it 
probably was a rediscovery, and every few years, someone independently 
publishes a new write-up, like this one:

   <https://arxiv.org/abs/1205.4011>

So if you want to truly address the vulnerability, you need to talk to 
authors of DNS server and request that *they* patch their software to 
avoid fragmentation.  BIND and Unbound use the special kernel support on 
Linux (something which is not necessary on the glibc side because it 
will send only packets shorter than the minimum Internet MTU), but both 
still default to 4096 byte EDNS buffers unfortunately, so they remain 
vulnerable to the fragmentation issue, depending on zone contents.

Thanks,
Florian