Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Talos Security Advisory for Systemd DHCP (TALOS-2020-1142/CVE-2020-13529) #16774

Closed
CiscoTalos opened this issue Aug 18, 2020 · 10 comments · Fixed by #20002
Closed

Talos Security Advisory for Systemd DHCP (TALOS-2020-1142/CVE-2020-13529) #16774

CiscoTalos opened this issue Aug 18, 2020 · 10 comments · Fixed by #20002
Labels
dhcp network security
Milestone
v249

Comments

@CiscoTalos
Copy link

CiscoTalos commented Aug 18, 2020 •
edited
Loading

Please review email issued to systemd-security at redhat dot com regarding this issue
@klnSVM
Copy link

klnSVM commented Apr 30, 2021

@yuwata are there any news regarding this vulnerability?
According to the Talos Advisory systemd maintainers told talos at the 4th of Dez 2020, that fixing the Issue is planned for the next release. Assuming form this point, it would have been v248.
Unfortunately I couldn't find any further information, if v248 fixed CVE-2020-13529 or not.
Could you please help me along?
Thanks!

@yuwata
Copy link
Member

yuwata commented Apr 30, 2021

@klnSVM The issue is not fixed yet. If I remember correctly, we discussed and concluded that if we use DHCP protocol then such the vulnerability always exists. Also, we could not find any RFC to avoid or mitigate the issue... So, I think it is hard to fix the issue soon on systemd-networkd side. Please let me know if you know relevant RFCs.

In short, we concluded that the vulnerability is not a issue of systemd-networkd but of DHCP protocol.

@keszybz Do you have any follow-ups?

@yuwata yuwata added the network label Apr 30, 2021
@yuwata
Copy link
Member

yuwata commented Apr 30, 2021 •
edited
Loading

Oh, I tried to find relevant RFCs again. Then, I found https://tools.ietf.org/html/rfc6704 which sounds related to the issue.

@yuwata
Copy link
Member

yuwata commented Apr 30, 2021 •
edited
Loading

I've not read RFC6704 in detail yet, but it should mitigate the issue. I will try to implement that.

@yuwata yuwata added this to the v249 milestone Apr 30, 2021
@keszybz
Copy link
Member

keszybz commented May 11, 2021

Also https://bugzilla.redhat.com/show_bug.cgi?id=1959398.

@ret2libc
Copy link
Contributor

@CiscoTalos Hi, it would be great if your report at https://talosintelligence.com/vulnerability_reports/TALOS-2020-1142 could reference a specific commit instead of just "master", otherwise it is hard to follow the code references because code changes quickly. Thanks!

@thom311
Copy link
Contributor

thom311 commented May 26, 2021

Since the DHCP client doesn't implement rfc3118 (Authentication for DHCP Messages) nor rfc6704 (Forcerenew Nonce Authentication), wouldn't a simple fix be to ignore any FORCERENEW messages?

If I am not wrong, then ISC's dhclient also does not support rfc3203/FORCERENEW, so this seems an acceptable thing not to support. And neither does nettools' n-dhcp4.

@StayPirate
Copy link

is there any update on that?

@yuwata
Copy link
Member

yuwata commented Jun 21, 2021

@StayPirate Unfortunately, not yet.

yuwata added a commit to yuwata/systemd that referenced this issue Jun 23, 2021
@yuwata
sd-dhcp-client: tentatively ignore FORCERENEW command
ab26925 
This makes DHCP client ignore FORCERENEW requests, as unauthenticated
FORCERENEW requests causes a security issue (TALOS-2020-1142, CVE-2020-13529).

Let's re-enable this after RFC3118 (Authentication for DHCP Messages)
and/or RFC6704 (Forcerenew Nonce Authentication) are implemented.

Fixes systemd#16774.
@yuwata yuwata mentioned this issue Jun 23, 2021
Merged
@yuwata
Copy link
Member

yuwata commented Jun 23, 2021

Fix is waiting in #20002.

yuwata added a commit to yuwata/systemd that referenced this issue Jun 24, 2021
@yuwata
sd-dhcp-client: tentatively ignore FORCERENEW command
38e980a 
This makes DHCP client ignore FORCERENEW requests, as unauthenticated
FORCERENEW requests causes a security issue (TALOS-2020-1142, CVE-2020-13529).

Let's re-enable this after RFC3118 (Authentication for DHCP Messages)
and/or RFC6704 (Forcerenew Nonce Authentication) are implemented.

Fixes systemd#16774.
@axg3073 axg3073 mentioned this issue Oct 26, 2021
Merged
OnkelUlla pushed a commit to OnkelUlla/systemd that referenced this issue Jan 15, 2023
@yuwata @keszybz
sd-dhcp-client: tentatively ignore FORCERENEW command
7078589 
This makes DHCP client ignore FORCERENEW requests, as unauthenticated
FORCERENEW requests causes a security issue (TALOS-2020-1142, CVE-2020-13529).

Let's re-enable this after RFC3118 (Authentication for DHCP Messages)
and/or RFC6704 (Forcerenew Nonce Authentication) are implemented.

Fixes systemd#16774.

(cherry picked from commit 38e980a)
(cherry picked from commit 3ec1234)
(cherry picked from commit f53d610)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
dhcp network security
Milestone
v249
Development

Successfully merging a pull request may close this issue.

sd-dhcp-client: ignore FORCERENEW yuwata/systemd
7 participants
@keszybz @ret2libc @thom311 @yuwata @StayPirate @CiscoTalos @klnSVM