1960834 - (CVE-2025-8036) VINCE Case VU#652514: DNS rebinding / CORS

Status: RESOLVED FIXED

(Core :: Networking, defect, P3)

Description

[Frederik Braun [:freddy]]

This is a copy of a report that we received through VINCE from the CERT/CC Vulnerability Coordination Team

Affected Vendor

Google
Google Apple Mozilla Microsoft

Affected Product

Google Chrome, Chromium, Edge, Safari, Firefox
#Affected Version
multiple - see How was the vulnerability discovered

Significant ICS/OT impact?

no

Reporter

Viktor Bocz [[e-mail]]
#Vendor contacted?
yes Description of the vulnerability, PoC code and video demonstration submitted to google. Issue is currently being triaged.

Description

This CORS bypass vulnerability combined with DNS rebind allows an attacker to send arbitrary requests to services listening on arbitrary ports regardless the CORS policies of the target.

##. Exploit
The attacker needs a webserver and a domain to perform the DNS rebind with.
The victim must visit the website controlled by the attacker.
The malicious site executes the javascript code that periodically sends POST and the preflight OPTIONS request to the attacker on the target port using the domain name.
The attacker hosted service responds to the preflight with permissive CORS headers.
The IP address of the A record is changed by the attacker to the target IP.
After the DNS responds with the changed IP, the javascript sends the POST request to the target. This request is successful regardless the CORS headers returned by the target.

Eg.
attacker IP - 87.65.43.21
target service - http://10.20.30.40:12345/xyz
DNS - www.cors.test - A record, low TTL (eg. 10s), initially resolves to 87.65.43.21

1. Victim visits http://87.65.43.21/
2. Javascript periodically (eg every second) sends POST to http://www.cors.test:12345/xyz (87.65.43.21).
3. Browser sends preflight OPTIONS request to the attacker that responds with permissive CORS headers (Access-Control-Allow-Origin: *, Access-Control-Allow-Headers: *)
4. Attacker updates A record so that www.cors.test resolves to 10.20.30.40
5. TTL expires, DNS is queried again, IP address changes to 10.20.30.40 on the victims device
6. the malicious javascript sends the request to http://www.cors.test:12345/xyz that at this point is 10.20.30.40:12345. Depending on the browser used and the frequency the POST requests are sent to the target the malicious request is sent to the target 1 or more times.
7. Browser sends another preflight OPTIONS request to the target that does not have the permissive CORS headers in the responses.
8. Browser stops sending the requests to the target due to the CORS policies.

The POST requests sent to the target are often not visible in the developer tools of the browsers. These were discovered in the packet capture.

Impact

Actual impact depends on the target.
The vulnerability was discovered while trying ways to send UPnP/IGD requests to a upnp server vulnerable to CVE-2021-29462 (libupnp dns rebind vulnerability) from the browser. By exploiting this browser vulnerability it was possible to set up port forwarding simply by visiting the malicious page.

Discovery

The discovery started by assessing the impact of having UPnP enabled on a gateway that used an old libupnp vulnerable to DNS rebind (CVE-2021-29462).
The UPnP service endpoint responded to the preflight request with code 503 and no CORS headers. Therefore, when sending the SOAP request to the UPnP/IGD endpoint using XHR the browser blocked it. After various failed attempts I checked what would happen if first I responded to the OPTIONS/POST requests with permissive CORS headers before the DNS IP is changed and to my surprise the request appeared in wireshark and the port mapping request was indeed successful.

I've written a quick and dirty python script that automatically performs all actions for the attack. It acts as the DNS server (automatically changes the IP 10s after the first DNS query), hosts the PoC malicious web page, exposes the service on the target port and responds to the POST and preflight requests with the permissive CORS headers.
To use it, change the TARGET_URL variable and run the script as python3 PoC-server-ext.py <listen IP> <attacker IP>

A simple flask service is also included in the archive that can be used as a target.

List of browsers that sent the request to the target:

Chromium 134.0.6998.35 (ubuntu 22.04.5)
Google Chrome 134.0.6998.88 (ubuntu 22.04.5)
Google Chrome 134.0.6998.89 (Windows 11 Version 23H2 (OS Build 22631.5039))
Microsoft edge 134.0.3124.66 (Windows 11 Version 23H2 (OS Build 22631.5039))
Safari 18.3.1 (20620.2.4.11.6) (Macos Sequoia 15.3.2 (24D81))

Firefox 136.0.2 (Ubuntu 22.04.5) - happens very rarely

Browsers that were never seen sending the POST to the target:

Opera GX core 117.0.5408.100 (Macos Sequoia 15.3.2 (24D81))
Firefox 136.0.1 (Android 14 on Samsung S24 Ultra)
Samsung Internet (Android 14 on Samsung S24 Ultra)

All tests were performed without disabling cache in the developer tools. All vulnerable browsers send several POST requests between preflights.

Comment 1

[Frederik Braun [:freddy]]

I am leaving this unconfirmed and as a task to go through and disambiguate between existing DNS rebinding bugs.
We should keep this bug hidden to respect coordinated disclosure.

As far as I understand, this is a typical DNS rebinding attack that does not add anything new. The exploit may be clever and rather harmful to the targeted endpoint (here: an upnp gateway), but I don't think it is "our" bug.
Web servers should check that the Host header matches theirs (and could even make use of Sec-Fetch headers nowadays.

Comment 2

[Daniel Veditz [:dveditz]]

Moving this to "Networking" because both DNS and CORS are involved.

We do know about DNS rebinding bugs, but I wonder if we could revoke cached CORS responses if the DNS changes? That could be hideous on a legit site with a short TTL, and I don't know if this risk is worth that.

Comment 3

[Daniel Veditz [:dveditz]]

As far as I understand, this is a typical DNS rebinding attack that does not add anything new. The exploit may be clever and rather harmful to the targeted endpoint (here: an upnp gateway), but I don't think it is "our" bug.

The part that might be "our" bug is that we're using cached CORS responses for the domain, and maybe that cache lifetime needs to be sensitive to changes in IP address, or limited to the DNS TTL.

Comment 4

[Valentin Gosu [:valentin]]

We do know about DNS rebinding bugs, but I wonder if we could revoke cached CORS responses if the DNS changes? That could be hideous on a legit site with a short TTL, and I don't know if this risk is worth that.

The default expiration time for cors preflight cache entries is 5 seconds - so treating them as expired when the DNS entry changes doesn't sound so radical. We allow a minimum TTL of 60 seconds for DNS, so even if we implement this mitigation, the increase in CORS preflights shouldn't be that big on most websites.

We'd have to make CORSCacheEntry hold a reference to the DNS cache entry then in CORSCacheEntry::CheckRequest check if the cache entry has changed or has expired.

Comment 5

[Frederik Braun [:freddy]]

Looks like this is still unassigned.

The CERT CC wants to know if we're truly affected and what our plans to fix this will look like.
Other browsers have started to comment and we should too.

Comment 6

[Kershaw Chang [:kershaw]]

Attachment: (secure)

Comment 7

[Kershaw Chang [:kershaw]]

Attachment: (secure)

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/47bb9492b5ec
https://hg.mozilla.org/integration/autoland/rev/624aa7227915
Don't use CORS cache if DNS entry has changed, r=necko-reviewers,valentin

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f88552aff6ab
https://hg.mozilla.org/integration/autoland/rev/790e3ebd41a9
Revert "Bug 1960834 - Don't use CORS cache if DNS entry has changed, r=necko-reviewers,valentin" for bc failures on browser_preflight_cache.js

Comment 10

[Kershaw Chang [:kershaw]]

Attachment: (secure)

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ef078f335fab
https://hg.mozilla.org/integration/autoland/rev/3e090ab7e001
Don't use CORS cache if DNS entry has changed, r=necko-reviewers,valentin
https://github.com/mozilla-firefox/firefox/commit/2e408a079ce3
https://hg.mozilla.org/integration/autoland/rev/39ce77ec537d
When proxy is used, skip checking DNS cache, r=necko-reviewers,valentin
https://github.com/mozilla-firefox/firefox/commit/d1e5a11f27a0
https://hg.mozilla.org/integration/autoland/rev/39c2659efc90
Test, r=necko-reviewers,valentin

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/57bd76b92b82
https://hg.mozilla.org/integration/autoland/rev/fccc41631f16
Revert "Bug 1960834 - Test, r=necko-reviewers,valentin" for causing wpt failures @ preflight-cache.htm

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out for causing wpt fails @ preflight-cache.htm

• Backout link
• Push with failures
• Failure Log

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4012daa1bca2
https://hg.mozilla.org/integration/autoland/rev/72985a666f18
Don't use CORS cache if DNS entry has changed, r=necko-reviewers,valentin
https://github.com/mozilla-firefox/firefox/commit/171b5ad0b3aa
https://hg.mozilla.org/integration/autoland/rev/aa1a0a1894c9
When proxy is used, skip checking DNS cache, r=necko-reviewers,valentin
https://github.com/mozilla-firefox/firefox/commit/57a2fabc439b
https://hg.mozilla.org/integration/autoland/rev/b430c917ec41
Test, r=necko-reviewers,valentin

Comment 15

[Kershaw Chang [:kershaw]]

Hi Pascal,

The patches for this bug have been landed, but the bug is still open.
Is it okay if I go ahead and close it myself?

Thanks.

Comment 16

[Pascal Chevrel:pascalc]

(In reply to Kershaw Chang [:kershaw] from comment #15)

Hi Pascal,

The patches for this bug have been landed, but the bug is still open.
Is it okay if I go ahead and close it myself?

Thanks.

I am doing it now.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:kershaw, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox140 to wontfix.

For more information, please visit BugBot documentation.

Comment 18

[Donal Meehan [:dmeehan]]

This will need requests for ESR128 and ESR140

Comment 19

[Kershaw Chang [:kershaw]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D251141

Comment 20

[Kershaw Chang [:kershaw]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D252302

Comment 21

[Kershaw Chang [:kershaw]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D251147

Comment 22

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Vulnerable to this DNS rebinding attack
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: Low
• Explanation of risk level: The worst case is CORS cache being not used and we could send more CORS requests
• String changes made/needed: N/A
• Is Android affected?: yes

Comment 23

[Kershaw Chang [:kershaw]]

Note: Uplifting the patches to ESR128 is not trivial, so I suggest not uplifting them to avoid potential risks.
I believe this is acceptable given the nature of the DNS rebinding issue, but please let me know if you disagree. Thanks!

Comment 24

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/d58b580bf120
https://hg.mozilla.org/releases/mozilla-esr140/rev/a679d07f47cf
https://hg.mozilla.org/releases/mozilla-esr140/rev/e06d161b7b81

Comment 25

[Simon Friedberger [:simonf]]

Attachment: advisory.txt