Opening http://../foo on Android Chrome crashes the browser (Warning: or worse) | Hacker News Reader

foo on Android Chrome crashes the browser (Warning: or worse)

bugs.chromium.org

105 pointsantoineaugusti84 comments

On XiaoMi phones at least, this is a system app (see: bloatware). That means you can't clear its app data nor uninstall it, effectively bricking Chrome permanently.

The only thing you can do is uninstall the updates, which force resets its persistence, losing all of your stored data/sessions.

If you've already done that... tough luck, I guess?

What an awful bug.

> That means you can't clear its app data nor uninstall it, effectively bricking Chrome permanently.

I foresee a "brickrolling" trend.

I have a Redmi Note 7 and it blocked chrome for a minute, but after closing and reopening it the issue resolved itself. Weird, seems very system dependant.

> On XiaoMi phones at least, this is a system app

You mean on Xaiomi OS's (I forget their name).

Miui

Yes, naturally.

I did this and was so furious the phone was bricked i threw my phone out a train window.... Was i too soon?

What are you typing this on?

His wristwatch.

That's wrong. You can clear both cache and data of a system app on a typical Android device. You just can't uninstall it.

The base .apk is stored on a read-only system partition, so you can't completely get rid of it, but typically you should be able to remove all data of that app, clear its cache, uninstall any updates it downloaded (since those are stored on another partition), and also disable it.

I haven't used any OS by Xiaomi in a while, so I don't know if they changed anything about that.

Though I used to run their MIUI OS on my Samsung Galaxy (S2 or S5, I don't remember) for a while. That one was the opposite of locked down and even shipped pre-rooted, but it's been a long time.

Nope. Chrome's storage lists "0b" for its storage, which causes XiaoMi's OS to grey out the memory panel for the app. You cannot, for whatever reason, clear the app cache in Chrome's case.

However, sure enough, tab instances persist even across killing the app and then force stopping it.

What happens if you disable?

Tangential... does that smell like built in spying tweaks to anyone else?

Edit - quick googling says Xiaomi have their own browser as default / system, is that what you're referring to?

The government of Lithuania actually did an investigation and found that Xiaomi phones spy on their users and contain a (disabled, probably intended for Chinese market) content filter system in their default browser.

Edit: source (in Dutch): https://www.security.nl/posting/721810/Litouwse+overheid%3A+... Source in Lithuanian: https://kam.lt/lt/naujienos_874/aktualijos_875/ka_daro_isman...

No. Chrome is also installed.

Have you tried closing the browser, reopen it and immediately hit the home button?

> Chrome freezes and/or crashes. Note: this is even worse if the URL was opened from an intent. In that case, Chrome can end up completely bricked because upon restart it will immediately attempt to re-open the URL that crashed it. I could not recover from this without having to fully "Clear Storage".

You’re telling me Chrome does not have that feature where after a few failed attempts, the browser offers you to not open the websites from the previous session? Firefox has that.

Windows has historically recovered from repeated unsafe shutdowns better than Linux.

Squeaky wheels getting grease, and such.

Only during updates, IME.

When I open https://bugs.chromium.org/p/chromium/issues/detail?id=125262... i get permission denied. Why am I getting "Permission denied" trying to view a bug?

It was marked security-sensitive some time within the last 14 hours. It was available to me when the link was submitted here on HN.

can anyone post a mirror? archive.org doesn't seem to support bugs.chromium.org :/

There wasn't anything there to be honest. Nobody had replied to it and it was still status:unconfirmed. The instructions were pretty bare - just visit the afflicted link.

There wasn't any response or activity prior to it being marked as private.

Warning: if you do this on your Android phone at the moment, you may have to completely clean your Chrome application storage to be able to use the app afterwards.

> Note: this is even worse if the URL was opened from an intent. In that case, Chrome can end up completely bricked because upon restart it will immediately attempt to re-open the URL that crashed it. I could not recover from this without having to fully "Clear Storage".

Too late for me. Not even from intent. Chrome force stop later, it still tries to load it and immediately crashes.

Off Topic: I don't get it why, after 10 years of mobile browser development, there still is no "close all tabs at end" option. Every time I visit my parents, I have to clean up their 150+ open chrome android tabs because they don't understand how to properly clean up their browsing sessions. Why on earth would I want to open the same old tabs in the morning, that I already looked at the day before?

Because they are the tabs with your email, facebook, news, and and and.

Is it really necessary to permanently monitor these distractions? (rhetorical question)

That’s what pinned tabs are for.

Because for a large number of people (including me) tabs are also bookmarks. Granted, most of them I’ll never get back to, but it’s a habit that’s difficult to break.

Yep, because you can't save all open tabs as bookmarks

That’s not the point, and sarcasm is uncalled for.

That's not sarcasm. Because this feature is missing on chrome android I only have the option to close all tabs or to manually open each tab and decide to bookmark it or not.

Ah, sorry. I was thinking of desktop browsers that do have the feature (but I don’t think I’ve ever used it as, well, I hardly use bookmarks).

I disable url bar autocompletion for history, so it's only for bookmarks and open tabs, and use my bookmarks as a way to choose which sites are easy to get to.

I think bookmarks on Desktop disappeared for a reason: They are not really useful. On Android, you can save "bookmarks" as symbol-links or install in case of PWAs. These symbols can be organized pretty good using the main Android interface. No need for a dedicated browser feature.

On Desktop, if I want to memorize a blog post etc., I use tools such as ArchiveBox, which also prevents later inaccessibility.

To memorize pages on Desktop, there're better features available that integrate more direcly on the OS level, e.g. similar to Android symbols.. There are also self hosted link organizers with tagging feature etc.

There are such options on Firefox. Auto close and close on quit, although annoyingly the latter now requires choosing quit from the app menu instead of just closing the app like a few years ago. There is also "close all tabs" if you just hold the tab button, as well as in the ... menu on the tab screen

You are right. My point is that you have to take steps to close tabs, if it is just "explicitly closing Firefox". On Desktop, the browser will be terminated on shutdown. Shutdown does not apply to phones. If I want to close all tabs the second I lock my phone - no such thing. It would be enough having a "Stop all Apps&Tabs at 12am" feature.

This is really why I avoid browsing things on my phone at all, or use self-hosted progressive web apps that run in dedicated tasks.

Btw. - can someone explain why my initial comment is downvoted - Is it because my use case appears ignorant or unusually extravagant?

Can you clear the app data via adb?

Could not be bothered to try (my daily driver on Android is Firefox)

Clearing cache was sufficient enough for me to launch Chrome and quickly close the tab.

I just closed chrome, reopened hit and immediately hit the home button at the top left. That was enough to get me to safety.

Thank you

Thanks for this, but I needed to disable animations in accessibility for this to work.

I just did and the whole phone was frozen. I couldn't force close Chrome, nor do a graceful power off. After 2 min, a notification came up that allowed me to finally close the browser.

Amazing how even after an army of contributors and a fairly old project still has bugs as trivial and yet significant as this one. It's a regression, but even so.

well most people work for $$ or for promotion so usually bug fixing is less important than landing some new privacy sandbox advertisement things. Also by reviewing code carefully doesn't make you stride the ladder. And if there are bugs they can just tell their manager we fixed this bug etc.And Google organization structure incentivize them. And now google has hegemony on Desktop browser and controls the engine they can get away easily. This is also probably reason why many products are simply killed by google.

Now to get some QR codes of that url printed on sticker paper...

Already in the mail!

I wont ask how you got my address.

Reminds me how in the first public release of Chrome you could crash the entire browser by typing % in the address bar.

Not sure what I expected. My poor tabs.

Surprised this wasn't submitted or treated by Google as a security defect. I don't think Google pays out for DoS typically, but considering how easily this can be weaponized, this one probably should've paid out.

Especially if the mechanism of the crash also allows for an RCE that hasn't been discovered yet. Worth equipping fuzzers with the URL as a prefix.

Edit: They reclassified it as a security defect and restricted permissions on it after my comment directly on the bug.

Absolutely. I'm surprised this isn't marked as critical.

If this was included in malicious emails and texts, it would block the use of Chrome on Android completely and the only current fix is to clear all browser data i.e. bookmarks, passwords etc.

Is "foo" used to mean any string, or is it literally only "../foo" that crashes it?

Any string, does not apply to brave so not a seemingly a webkit issue

It wouldn't be. Neither Brave nor Chrome use WebKit.

Unless you're on iOS, in which case Chrome/Brave/all are just a crude wrapped for Safari/WebKit.

Strangely this bug does not seem to occur in incognito mode, at least on my phone.

Did this to Chrome on Android & it crashed, but only for the first time. Subsequent requests simply took me to google search results instead of resolving the URL.

On older versions of Chrome just goes to google.com and searches for this string. That's why i disabled automatic updates on my phone. Give me a changelog and i update. Bug fixes and performance improvements it's not a changelog.

Yeah I am in the same boat - however most apps just have a changelog message similar to "We cleaned the app under the hood. It works now better."

i stopped bothering about that.

i used to not like updated, and just postponed them. then noticed that after a while android would just update everything silently (without my consent).

so i guess... whatever, it's a lost cause. I hate modern smartphones.

Works as expected on Brave (it's Chromium based)

You mean bricking/crashing or nothing ?

It depends on whether you're aware of this issue or not.

The bug report contains expected result "DNS resolution error, or some kind of non-fatal error in general." - so that's what I meant by works as expected. It just shows DNS failure page, it does not crash the browser.

Not an issue in Bromite or GrapheneOS' Vanadium chromium fork.

edit: correction: it effects both. Incognito tabs aren't affected.

Well, mine did brick on Vanadium. Didn't try Bromite.

Actually it affects both. I was using Incognito to test it out. Turns out it doesn't work in incognito.

doesn't work for me on kiwi 94 (a fork of chrome)

https://imgur.com/a/pBtuwRW

maybe you need to be not in incognito? i didn't want to test out of it in case it actually bricks my browser

Doesn't crash for me. Takes me to Google search.

My bet is on url parser in unsafe language

You realize "safe" languages don't protect you from all bugs, right?

So tired of this narrative on HN.

From some bugs (or serious consequences in fact) they do, don't they?

You can easily shoot yourself in the foot in any language.

For one thing that are plenty of toy languages where you'd be lucky to do anything in particular, including shoot yourself in the foot, "easily".

But also there are languages which have much higher bars for safety than you seem to have imagined. Notice how WUFFS doesn't have a "Hello, world." example program because printing out Hello, World is way too dangerous to be allowed in WUFFS even on purpose.

Unsafe code can make even safe and correct code behave unpredictably, which is a lot more dangerous than merely crashing in an obvious way.

But actual crashes are most likely due to memory unsafety; I’d be extremely surprised if the root cause was not found to be in a memory-unsafe language, though I doubt it’ll be in the URL parser.

That's a weak statement: isn't Chrome is almost entirely written in C++? I suppose you mean it's a memory overrun or use are free. You're probably right, then.

But in Rust, something like this could happen too, if someone added a panic!, e.g. on parsing a domain name with an empty component, or failure to put the domain name in a certain (external) structure. If the URL is parsed again on start-up, the application would be bricked. Granted, it's much easier to find and solve.

I would guess that various parts of Chrome for Android, especially its UI, might be in a memory-safe language. But yeah, in hindsight my word choice was poor; I should have said a root cause of memory unsafety.

As for Rust, if we’re talking about outright crashes (which on reflection I’m not sure if we actually are because of laxness in the definition of “crash”—I retract my proffered extreme surprise), panicking isn’t that (unless compiled with abort-on-panic or if a destructor panics while unwinding)—panicking is controlled and can (except for the cases already mentioned) be caught.

To be sure, you can still brick the app in the described way with persisted data triggering exceptions or panicking, but there at least can still be a difference.

an uncaught exceptions or an abort can kill an application even on a safe language.

Memory safe languages also have crashes, often uncaught exceptions, or explicit calls to abort() or similar functions (die, panic, etc...). Infinite recursion, and the resulting stack overflow is another common cause of crash that can happen in any language.

In fact, a crash (segmentation fault) is an exception. In theory, the program could catch it and try to recover from it, it is just that it is a terrible thing to do because you can't be sure of anything from now one.

In fact, letting the program crash is the basis of "offensive programming". This idea opposes the idea of defensive programming, where you try to be prepared for anything and try to do something sensible. In offensive programming, you crash when things are not as expected. For example, if you ask for the 5th element of a 4 element list, in the former, you return some kind of default value, in the latter, you crash with an "out of bounds" exception, or let a watchdog restart the system.

Both approaches have their pros and cons.

My bet is URL parser with insufficient tests.

It is well known that URLs are hard; nobody should ever trust their own implementation of a URL parser unless it is sufficiently tested (payload repositories exist for a reason).

And under circumstances testing the own url parser _alone_ is only half (?) of the story. The other URL parsers within the system or in the line need to be tested, too. Which mathematically might not be possible. So next to the URL parser it is likely practically to have an URL filter. And with it, a good test-suite, too.

(I don't do any bets thought, sorry)

Reply on news.ycombinator.com