[HN Gopher] Opening http://../foo on Android Chrome crashes the ...
___________________________________________________________________
Opening http://../foo on Android Chrome crashes the browser
(Warning: or worse)
Author : antoineaugusti
Score : 98 points
Date : 2021-09-24 07:55 UTC (15 hours ago)
(HTM) web link (bugs.chromium.org)
(TXT) w3m dump (bugs.chromium.org)
| SimeVidas wrote:
| > 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.
| atatatat wrote:
| Windows has historically recovered from repeated unsafe
| shutdowns better than Linux.
|
| Squeaky wheels getting grease, and such.
| pritambaral wrote:
| Only during updates, IME.
| totetsu wrote:
| Now to get some QR codes of that url printed on sticker paper...
| drug5 wrote:
| Already in the mail!
| totetsu wrote:
| I wont ask how you got my address.
| chrismorgan wrote:
| Reminds me how in the first public release of Chrome you could
| crash the entire browser by typing % in the address bar.
| hulitu wrote:
| 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.
| znpy wrote:
| 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.
| chinathrow wrote:
| 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."
| aufhebung wrote:
| Strangely this bug does not seem to occur in incognito mode, at
| least on my phone.
| eganist wrote:
| 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.
| edgall wrote:
| 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.
| sigmonsays wrote:
| 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?
| Arnavion wrote:
| 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.
| tssva wrote:
| Doesn't crash for me. Takes me to Google search.
| kklisura wrote:
| Works as expected on Brave (it's Chromium based)
| Scoundreller wrote:
| You mean bricking/crashing or nothing ?
| NullPrefix wrote:
| It depends on whether you're aware of this issue or not.
| kklisura wrote:
| 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.
| 0xdeadb00f wrote:
| Not an issue in Bromite or GrapheneOS' Vanadium chromium fork.
|
| edit: correction: it effects both. Incognito tabs aren't
| affected.
| ptidhomme wrote:
| Well, mine did brick on Vanadium. Didn't try Bromite.
| 0xdeadb00f wrote:
| Actually it affects both. I was using Incognito to test it
| out. Turns out it doesn't work in incognito.
| antoineaugusti wrote:
| 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.
| clon wrote:
| > 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.
| david_allison wrote:
| Can you clear the app data via adb?
| clon wrote:
| Could not be bothered to try (my daily driver on Android is
| Firefox)
| Helmut10001 wrote:
| 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?
| mod50ack wrote:
| 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
| Sharlin wrote:
| 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.
| croes wrote:
| Yep, because you can't save all open tabs as bookmarks
| Sharlin wrote:
| That's not the point, and sarcasm is uncalled for.
| croes wrote:
| 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.
| Sharlin wrote:
| 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).
| soco wrote:
| Because they are the tabs with your email, facebook, news,
| and and and.
| Helmut10001 wrote:
| Is it really necessary to permanently monitor these
| distractions? (rhetorical question)
| loloquwowndueo wrote:
| That's what pinned tabs are for.
| Namidairo wrote:
| Clearing cache was sufficient enough for me to launch Chrome
| and quickly close the tab.
| cafxx wrote:
| I just closed chrome, reopened hit and immediately hit the
| home button at the top left. That was enough to get me to
| safety.
| garibarba wrote:
| Thanks for this, but I needed to disable animations in
| accessibility for this to work.
| croes wrote:
| Thank you
| exciteabletom wrote:
| Is "foo" used to mean any string, or is it literally only
| "../foo" that crashes it?
| guywhocodes wrote:
| Any string, does not apply to brave so not a seemingly a webkit
| issue
| pwdisswordfish8 wrote:
| It wouldn't be. Neither Brave nor Chrome use WebKit.
| atatatat wrote:
| Unless you're on iOS, in which case Chrome/Brave/all are
| just a crude wrapped for Safari/WebKit.
| [deleted]
| tester34 wrote:
| My bet is on url parser in unsafe language
| junon wrote:
| You realize "safe" languages don't protect you from all bugs,
| right?
|
| So tired of this narrative on HN.
| erik_seaberg wrote:
| Unsafe code can make even safe and correct code behave
| unpredictably, which is a lot more dangerous than merely
| crashing in an obvious way.
| chrismorgan wrote:
| 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.
| tgv wrote:
| 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.
| chrismorgan wrote:
| 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.
| gpderetta wrote:
| an uncaught exceptions or an abort can kill an application
| even on a safe language.
| tester34 wrote:
| From some bugs (or serious consequences in fact) they do,
| don't they?
| junon wrote:
| You can easily shoot yourself in the foot in any language.
| tialaramex wrote:
| 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.
| DarkWiiPlayer wrote:
| 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).
| hakre wrote:
| 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)
| throwaway3b03 wrote:
| 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.
| cute_boi wrote:
| 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.
| junon wrote:
| 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.
| thaumasiotes wrote:
| > That means you can't clear its app data nor uninstall it,
| effectively bricking Chrome permanently.
|
| I foresee a "brickrolling" trend.
| chmod775 wrote:
| 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.
| junon wrote:
| 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.
| akdor1154 wrote:
| 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?
| junon wrote:
| No. Chrome is also installed.
| sjamaan wrote:
| 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/7218
| 10/Litouwse+overheid%3A+... Source in Lithuanian: https://kam
| .lt/lt/naujienos_874/aktualijos_875/ka_daro_isman...
| croes wrote:
| Have you tried closing the browser, reopen it and immediately
| hit the home button?
| uap wrote:
| I did this and was so furious the phone was bricked i threw my
| phone out a train window.... Was i too soon?
| ghuin wrote:
| What are you typing this on?
| Joker_vD wrote:
| His wristwatch.
| thevinter wrote:
| 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.
| BelenusMordred wrote:
| > On XiaoMi phones at least, this is a system app
|
| You mean on Xaiomi OS's (I forget their name).
| ghuin wrote:
| Miui
| junon wrote:
| Yes, naturally.
| DarthNebo wrote:
| 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.
| r3muxd wrote:
| 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
| meibo wrote:
| Not sure what I expected. My poor tabs.
___________________________________________________________________
(page generated 2021-09-24 23:02 UTC)