| 2017-06-02 21:52:24 |
Chris Coulson |
bug |
|
|
added bug |
| 2017-06-02 21:52:24 |
Chris Coulson |
attachment added |
|
break-tcp.py https://bugs.launchpad.net/bugs/1695546/+attachment/4888093/+files/break-tcp.py |
|
| 2017-06-06 11:29:50 |
Chris Coulson |
cve linked |
|
2017-9445 |
|
| 2017-06-06 11:37:12 |
Chris Coulson |
description |
Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. On x86, a page-aligned number - 80 will do this. Eg, calling dns_packet_new with a size of 4016 will result in an allocation of 4096, but 108 bytes of this are for the DnsPacket struct.
A malicious TCP server can exploit this with specially crafted responses to trick systemd-resolved in to allocating a buffer that's too small, which allows it to write arbitrary data beyond the end of it.
To demonstrate this you can run the attached python script. This is a mock DNS server that sends a response where the first two bytes specify a size of 4016 (note, this size is picked to trigger an out of bounds write on x86 - you'll probably need to pick a different number for x86-64). You'll also need to temporarily set your DNS server to 127.0.0.1. |
Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this - so, on x86 this will be a page-aligned number - 80. Eg, calling dns_packet_new with a size of 4016 will result in an allocation of 4096, but 108 bytes of this are for the DnsPacket struct.
A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.
To demonstrate this you can run the attached python script. This is a mock DNS server that sends a response where the first two bytes specify a size of 4016 (note, this size is picked to trigger an out of bounds write on x86 - you'll probably need to pick a different number for x86-64). You'll also need to temporarily set your DNS server to 127.0.0.1. |
|
| 2017-06-06 14:07:07 |
Chris Coulson |
description |
Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this - so, on x86 this will be a page-aligned number - 80. Eg, calling dns_packet_new with a size of 4016 will result in an allocation of 4096, but 108 bytes of this are for the DnsPacket struct.
A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.
To demonstrate this you can run the attached python script. This is a mock DNS server that sends a response where the first two bytes specify a size of 4016 (note, this size is picked to trigger an out of bounds write on x86 - you'll probably need to pick a different number for x86-64). You'll also need to temporarily set your DNS server to 127.0.0.1. |
Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this - so, on x86 this will be a page-aligned number - 80. Eg, calling dns_packet_new with a size of 4016 will result in an allocation of 4096, but 108 bytes of this are for the DnsPacket struct.
A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.
To demonstrate this you can run the attached python script. This is a mock DNS server that sends a response where the first two bytes of the TCP payload specify a size of 4016 (note, this size is picked to trigger an out of bounds write on x86 - you'll probably need to pick a different number for x86-64). You'll need to temporarily set your DNS server to 127.0.0.1. |
|
| 2017-06-06 14:09:00 |
Chris Coulson |
bug |
|
|
added subscriber Dimitri John Ledkov |
| 2017-06-06 16:03:05 |
Dimitri John Ledkov |
systemd (Ubuntu): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-06-06 16:03:07 |
Dimitri John Ledkov |
systemd (Ubuntu): importance |
Undecided |
High |
|
| 2017-06-06 16:03:32 |
Dimitri John Ledkov |
systemd (Ubuntu): milestone |
|
ubuntu-17.06 |
|
| 2017-06-14 04:54:13 |
Dimitri John Ledkov |
attachment added |
|
lp1695546.patch https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1695546/+attachment/4895609/+files/lp1695546.patch |
|
| 2017-06-14 04:54:29 |
Dimitri John Ledkov |
bug |
|
|
added subscriber Steve Langasek |
| 2017-06-14 04:54:47 |
Dimitri John Ledkov |
bug |
|
|
added subscriber Martin Pitt |
| 2017-06-14 19:23:07 |
Chris Coulson |
description |
Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this - so, on x86 this will be a page-aligned number - 80. Eg, calling dns_packet_new with a size of 4016 will result in an allocation of 4096, but 108 bytes of this are for the DnsPacket struct.
A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.
To demonstrate this you can run the attached python script. This is a mock DNS server that sends a response where the first two bytes of the TCP payload specify a size of 4016 (note, this size is picked to trigger an out of bounds write on x86 - you'll probably need to pick a different number for x86-64). You'll need to temporarily set your DNS server to 127.0.0.1. |
Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this - so, on x86 this will be a page-aligned number - 80. Eg, calling dns_packet_new with a size of 4016 will result in an allocation of 4096 bytes, but 108 bytes of this are for the DnsPacket struct.
A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.
To demonstrate this you can run the attached python script. This is a mock DNS server that sends a response where the first two bytes of the TCP payload specify a size of 4016 (note, this size is picked to trigger an out of bounds write on x86 - you'll probably need to pick a different number for x86-64). You'll need to temporarily set your DNS server to 127.0.0.1. |
|
| 2017-06-27 15:43:58 |
Launchpad Janitor |
systemd (Ubuntu): status |
New |
Fix Released |
|
| 2017-06-27 15:43:59 |
Launchpad Janitor |
systemd (Ubuntu): status |
New |
Fix Released |
|
| 2017-07-10 15:01:48 |
Steve Beattie |
information type |
Private Security |
Public Security |
|
| 2017-07-10 15:03:16 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-07-10 15:03:16 |
Dimitri John Ledkov |
bug task added |
|
systemd (Ubuntu Xenial) |
|
| 2017-07-10 15:03:16 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-07-10 15:03:16 |
Dimitri John Ledkov |
bug task added |
|
systemd (Ubuntu Yakkety) |
|
| 2017-07-10 15:03:16 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Artful |
|
| 2017-07-10 15:03:16 |
Dimitri John Ledkov |
bug task added |
|
systemd (Ubuntu Artful) |
|
| 2017-07-10 15:03:16 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-07-10 15:03:16 |
Dimitri John Ledkov |
bug task added |
|
systemd (Ubuntu Zesty) |
|
| 2017-07-10 15:03:24 |
Dimitri John Ledkov |
systemd (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-07-10 15:03:29 |
Dimitri John Ledkov |
systemd (Ubuntu Yakkety): status |
New |
Fix Released |
|
| 2017-07-10 15:03:31 |
Dimitri John Ledkov |
systemd (Ubuntu Zesty): status |
New |
Fix Released |
|
| 2017-07-10 15:05:33 |
Dimitri John Ledkov |
description |
Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this - so, on x86 this will be a page-aligned number - 80. Eg, calling dns_packet_new with a size of 4016 will result in an allocation of 4096 bytes, but 108 bytes of this are for the DnsPacket struct.
A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.
To demonstrate this you can run the attached python script. This is a mock DNS server that sends a response where the first two bytes of the TCP payload specify a size of 4016 (note, this size is picked to trigger an out of bounds write on x86 - you'll probably need to pick a different number for x86-64). You'll need to temporarily set your DNS server to 127.0.0.1. |
[Impact]
Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this - so, on x86 this will be a page-aligned number - 80. Eg, calling dns_packet_new with a size of 4016 will result in an allocation of 4096 bytes, but 108 bytes of this are for the DnsPacket struct.
A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.
To demonstrate this you can run the attached python script. This is a mock DNS server that sends a response where the first two bytes of the TCP payload specify a size of 4016 (note, this size is picked to trigger an out of bounds write on x86 - you'll probably need to pick a different number for x86-64). You'll need to temporarily set your DNS server to 127.0.0.1.
[Testcase]
Launch the attached script on i386, point resolved at the started dns server, execute a dns query via resolved observe that it crashes.
Upgrade systemd package and observe that resolved no longer crashes.
[Regression Potential]
Low, resolved is not used by default in xenial. This is a bug fix to resolved, in case somebody does use resolved in xenial. |
|
| 2017-07-10 15:33:30 |
Łukasz Zemczak |
systemd (Ubuntu Xenial): status |
Confirmed |
Fix Committed |
|
| 2017-07-10 15:33:33 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-07-10 15:33:36 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2017-07-10 15:33:40 |
Łukasz Zemczak |
tags |
|
verification-needed verification-needed-xenial |
|
| 2017-07-12 11:08:29 |
Dimitri John Ledkov |
tags |
verification-needed verification-needed-xenial |
verification-done verification-done-xenial |
|
| 2017-07-18 23:34:41 |
Adam Conrad |
tags |
verification-done verification-done-xenial |
verification-needed verification-needed-xenial |
|
| 2017-07-20 14:19:58 |
Dimitri John Ledkov |
tags |
verification-needed verification-needed-xenial |
verification-done verification-done-xenial |
|
| 2017-07-20 23:43:33 |
Adam Conrad |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-07-20 23:43:25 |
Launchpad Janitor |
systemd (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
