For those who have access to flags, incognito #1100
Replies: 9 comments 38 replies
-
looks like the incognito exploit is back but easier?! |
Beta Was this translation helpful? Give feedback.
-
i think you doxxed your school i think you should edit and delete the first revision |
Beta Was this translation helpful? Give feedback.
-
IT WORKS |
Beta Was this translation helpful? Give feedback.
-
uh it opened the old incognito exploit captive tab too (separately) lol i tried using the old incognito exploit DNS (52.207.185.90) but it didn't work i guess it did but i didn't get the sign in popup?? |
Beta Was this translation helpful? Give feedback.
-
Here's a version I wrote on this Instructions:
Notes: Credits: |
Beta Was this translation helpful? Give feedback.
-
lots of people xd its just me yapping ngl why are more people not actually talking about this- it's actually good |
Beta Was this translation helpful? Give feedback.
-
does this still work? im on v126 and after activating the flag the signin popup doesnt open in a seperate portal, just in a chrome tab |
Beta Was this translation helpful? Give feedback.
-
no longer works on 128 :( |
Beta Was this translation helpful? Give feedback.
-
https://crbug.com/341245382 (not by me, i did not discover this)
DESCRIPTION [email protected] created issue #1Security Bug
Important: Please do not change the component of this bug manually.
Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md
Please see the following link for instructions on filing security bugs: https://www.chromium.org/Home/chromium-security/reporting-security-bugs
Reports may be eligible for reward payments under the Chrome VRP: https://g.co/chrome/vrp
NOTE: Security bugs are normally made public once a fix has been widely deployed.
VULNERABILITY DETAILS
On Chrome OS, you can open an Incognito browsing window through the flag #captive-portal-popup-window even when the policy IncognitoModeAvailability equals 1 which should disable Incognito mode.
VERSION
Chrome Version: Tested on 124.0.6367.154 (Official Build) (64-bit), but the code path is still present in the HEAD on Chromium Code Search.
Operating System: Chrome OS 124.0.6367.154 (Official Build) (64-bit)
REPRODUCTION CASE
NOTE: You can also right-click -> View Source if DeveloperToolsAvailability allows such.
CODE PATH
The main problem is here. It explicitly checks if Incognito is disabled by policy, but if it is, it runs the same code as if not. The comment says:
Since the signin window enables extensions and disables navigation, no special handling is required when Incognito browsing is disabled by policy.
But the function it calls (definition here) uses an OTR profile regardless of IncognitoModeAvailability, and does not enable extensions as the comment asserts. To fix the problem, I would change the first file (chrome/browser/ui/ash/network/network_portal_signin_controller.cc) to not open the popup window if Incognito is disabled, as even if only the Control-T is disabled as a "fix", one can still run their own DNS server which will display something like Google in the captive portal, and bypass filtering.
FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
N/A
CREDIT INFORMATION
Externally reported security bugs may appear in Chrome release notes. If this bug is included, how would you like to be credited?
Reporter credit: @️joshuajohncohen (GitHub)
Instructions for skids:
EDIT:
THIS IS NOT MY SCHOOL, THIS IS THE IMAGE FROM THE BUG REPORT I ATTACHED.
If this gets patched, it is not my fault. This is listed as a Severity 4 Priority 4 Security Bug on the bug reporter.
I don't know if this is the correct dns, but lots of people say you can use
detectportal.firefox.com
as the DNSBeta Was this translation helpful? Give feedback.
All reactions