Published Jun 24, 2019
Crosh is a Command Shell environment known as “Chrome Shell” that is provided with Chrome OS. It is very similar to Command Prompt on Windows or Terminal in macOS devices. Crosh allows users to run several commands directly from ChromeOS. The vast majority of Linux commands are locked down inside CROSH. Crosh Window needs to be launched twice to get a working window. The first launch of Crosh Window shows a blank area without the shell, the second launch works as expected with crosh prompt & shell appearing. Workaround: launch crosh in the browser first (Ctrl-Alt-T) and then launch Crosh Window. Note: Before executing commands, you need to start Crosh on your device, by following the below method; To Startup Crosh, press CTRL+ALT+T keys at once. Crosh will open up in Chrome. Learning Chrome Shell (Crosh) Similar to Command Prompt on Windows, Bash in Linux and Terminal on macOS, Chrome OS has its command line called Chrome Shell (Crosh). It allows you to modify many system settings that are otherwise not available in Settings or Flags page. So, if you want to dive deep into Chrome OS, you must learn what Crosh. Crosh which is Command Shell environment known as “Chrome Shell” allows users to directly execute commands from Chrome Os. Most of the Linux commands that you may be looking for to hack your Chromebook using crosh are locked, but you can unlock them by accessing the google admin console How to Hack Chromebook using Crosh.
U2F ECDSA vulnerability
This page provides technical background and advice to users who are affected by a security vulnerability in Chrome OS' experimental 'built-in security key' feature that implements an authenticator in accordance with the Universal 2nd Factor specification.
If you're not interested in technical detail, but just want to fix your account security, just follow these steps:
Double-check whether you're affected: This is about the experimental built-in security key function where your Chromebook acts as a security key that you can trigger by pressing the Chromebook's power button. If you have never used this feature, you can stop reading now.
Make a list of your accounts with websites etc. where you have registered the built-in security key. These are at risk because the built-in security key can potentially be faked by an attacker without the attacker having your Chrome OS device.
Unregister the built-in security key from all these services. Exact instructions vary by service, but typically there are 'account settings' or 'security settings' that list registered security keys and give you the option to remove / unregister security keys. There is no need to change passwords or other account security settings.
(optional) Review recent successful logins to services to determine whether there's anything suspicious.
In case you received a 'Internal security key requires reset' notification, click 'Reset' on the notification to prevent it from showing again.
That's it, you're good. You can stop reading at this point unless you are interested in further technical details.
Vulnerability description
We discovered a vulnerability in the H1 security chip firmware concerning ECDSA signature generation. The firmware code used incompatible transfer instructions when passing a critical secret value to the cryptographic hardware block, resulting in generating secret values of a specific structure and having a significant loss of entropy in the secret value (64 bits instead of 256 bits). We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the the underlying ECC private key to be obtained. Thus, attackers that have a single pair of signature and signed data can effectively compute the private key, breaking any functionality or protocols that use the key pair in question.
Impacted features
ECDSA signatures generated by H1 were only used by Chrome OS for the experimental built-in U2F authenticator. An attacker who observes a signature produced by the built-in U2F authenticator can thus obtain the private key and spoof the authenticator from that point on. In other words, correct signatures no longer provide a strong signal of possession of the corresponding Chrome OS device.
Note that signatures are generated both when the U2F authenticator gets registered with a service, and when processing an authentication challenge (e.g. when logging in to a 2FA-enabled service using the built-in U2F authenticator).
We don't expect the vulnerable signatures to have been exposed broadly as they will usually be passed across HTTPS connections. However, since the signature is not considered sensitive in the U2F protocols, it would be inadequate to assume that no signatures have been observed or logged / stored in locations where they still may be retrieved from. As such, the built-in U2F authenticator feature that has generated vulnerable signatures using the vulnerable H1 firmware must be considered cryptographically broken.
In practice, even the cryptographically broken U2F implementation as described above still doesn't immediately cause account compromise. For one, the primary factor in two-factor-authentication scheme remains unaffected. Secondly, even the broken U2F implementation provides phishing protection against most attackers since they won't easily be able to obtain a signature to break. Specifically, obtaining signatures is complicated by the U2F protocol creating individual keys for each service that a security key is enrolled with.
Nevertheless, we recommend users to take remediation steps as described below to avoid the risk of running with a cryptographically weakened U2F authenticator.
Remediation
Full remediation requires both a firmware fix and retiring key pairs that have generated vulnerable signatures.
Firmware fix
Fixed firmware for the H1 security chip has been shipping with Chrome OS version 75 and later and the update has automatically been installed on devices. No user action is required to get the firmware fix. Concerned users can double-check the H1 firmware version as described below to verify they've been updated to fixed firmware. The fixed firmware no longer generates vulnerable signatures. Note that this doesn't retroactively 'fix' affected key pairs that have previously generated vulnerable signatures, these can still be broken if a vulnerable signature is available to an attacker.
Retiring affected ECDSA keys
Each registration of the built-in U2F authenticator with a service has a corresponding ECDSA key. All keys that have produced vulnerable signatures are no longer secure, so should no longer be trusted by services. Unfortunately there is no way to centrally revoke security keys, so users need to manually unregister the built-in U2F authenticator from services. See the advice above for more details.
Crosh Commands Hack On Steam
Affected versions
Production H1 firmware versions with a version number of 0.3.14 and earlier contain the vulnerability. Versions 0.3.15 and later are not vulnerable. The H1 firmware version is listed on the chrome://system page under cr50_version, specifically the RW line.
Fixed H1 firmware versions are shipping with Chrome OS version 75 and later and get automatically installed by the OS. Note that the firmware will never get downgraded, so even if you downgrade to an earlier OS version, the fixed firmware will keep running on the device.
Affected devices
All shipping devices that have an H1 security chip are potentially affected. A full list of models with public codename (listed in Platform or Customization ID on the chrome://version page) and model name is given below.
akali360 - Acer Chromebook Spin 13 (CP713-1WN)
akali - Acer Chromebook 13 (CB713-1W)
alan - HP Chromebook 11 G6 EE
aleena - Acer Chromebook 315
ampton - ASUS Chromebook Flip C214
apel - ASUS Chromebook C204
astronaut - Acer Chromebook 11 (C732)
babymako - ASUS chromebook C403
babymega - ASUS Chromebook C223
babytiger - ASUS Chromebook C523
barla - HP Chromebook 11A G6 EE
basking - ASUS Chromebook C213NA/C213SA
bigdaddy - HP Chromebook 14 / HP Chromebook 14 G5
blacktip360 - CTL chromebook NL7T-360
blacktip - CTL chromebook NL7
blacktiplte - CTL Chromebook NL7 LTE
blue - Acer Chromebook 15 CB315-1H / 1HT
bobba360 - Acer Chromebook Spin 511
bobba - Acer Chromebook 311
bob - ASUS Chromebook Flip C101PA
bruce - Acer Chromebook Spin 15 CP315-1H / 1HT
careena - HP Chromebook 14 db0000-db0999
dru - Acer Chromebook Tab 10 (D651N / D650N)
druwl - CTL Chromebook Tab Tx1
dumo - ASUS Chromebook Tablet CT100
electro - Acer Chromebook Spin 11 (R751T / CP511)
epaulette - Acer Chromebook 514
eve - Google Pixelbook
fleex - Dell Chromebook 3100
grabbiter - Dell Chromebook 3100 2in1
kasumi360 - Chromebook Spin 311 (R721T)
kasumi - Chromebook 311 (C721)
kench - HP Chromebox G2
lava - Acer Chromebook Spin 11 (CP311-1H & CP311-1HN)
liara - Lenovo 14e Chromebook
meep - HP Chromebook x360 11 G2 EE
mimrock - HP Chromebook 11 G7 EE
nasher360 - Dell Chromebook 11 2-in-1 5190
nasher - Dell Chromebook 11 5190
nautiluslte - Samsung Chromebook Plus (LTE)
nautilus - Samsung Chromebook Plus (V2)
nocturne - Pixel Slate
orbatrix - Dell Chromebook 3400
pantheon - Yoga C630 Chromebook
phaser360 - Lenovo 300e/500e Chromebook 2nd Gen
phaser - Lenovo 100e Chromebook 2nd Gen
pyro - Lenovo Thinkpad 11e Chromebook (4th Gen)/Lenovo Thinkpad Yoga 11e Chromebook (4th Gen)
rabbid - ASUS Chromebook C423
robo360 - Lenovo 500e Chromebook
robo - Lenovo 100e Chromebook
sand - Chromebook 15 (CB515 - 1HT / 1H)
santa - Acer Chromebook 11 (CB311 - 8H / 8HT)
shyvana - ASUS Chromebook Flip C434
sion - Acer Chromebox CXI3
snappy - HP Chromebook x360 11 G1 EE
sona - HP Chromebook x360 14
soraka - HP Chromebook x2
sparky360 - Acer Chromebook Spin 512(R851TN)
sparky - Acer Chromebook 512(C851/C851T)
syndra - HP Chromebook 15 G1
teemo - ASUS Chromebox 3
vayne - Dell Inspiron Chromebook 14 2-in-1 7486
whitetip - CTL Chromebook J41 / J41T
whitetip - PCmerge Chromebook AL116
whitetip - Prowise Chromebook Eduline
whitetip - Sector 5 E3 Chromebook
whitetip - Viglen Chromebook 11C
wukong - CTL Chromebox CBx1
wukong - Promethean Chromebox
wukong - ViewSonic NMP660 Chromebox
This section provides answers for situations we expect users to find themselves in.
I have been getting a notification saying 'Internal security key requires reset'. Is this related?
Yes. Chrome OS M76 shows a system notification on all devices that have the legacy built-in U2F authenticator feature enabled manually via crosh. Note that the notification triggers on whether the feature is enabled, regardless of whether you have actually used the U2F authenticator with any services. If you have registered the built-in U2F authenticator with any services, please unregister as explained above.
There's no good reason to continue using the legacy feature that was enabled via u2f_flags u2f or u2f_flags g2f, but users should switch to the improved implementation, which the 'Reset' button on the notification will do for you without having to go through crosh.
I can't live without the built-in U2F authenticator. What to do?
The good news is that we have been working on an improved implementation of the built-in U2F authenticator feature for a while. This will not only be unaffected by the bug since it never generated signatures that have the vulnerability, but it also has other security improvements. In particular the improved implementation now respects user boundaries, i.e. each Chrome OS user has their own virtual instance of an U2F authenticator. Also, the underlying encryption keys get discarded when you go through powerwash, recovery, or switch to developer mode.
The new implementation is still not officially launched, but can be tried out at this point. To enable, open crosh and type u2f_flags u2f,user_keys. Note that existing registrations with services (which you should have removed per the advice above on this page) will no longer work, so you need to re-register the built-in U2F authenticator with any services.
I have lost access to a service that had the built-in U2F authenticator configured as the only valid security key. Help!
Crosh Commands Hack On Roblox
You can temporarily re-enable the legacy implementation of the built-in U2F authenticator by issuing the u2f_flags u2f in crosh (see also the question on u2f_flags behavior). Your old registrations should now work again. After you regain access to the affected service, please turn the legacy U2F authenticator off again.
How do the various u2f_flags commands in crosh affect behavior?
The u2f_flags command in crosh allows you to control the behavior of the built-in U2F authenticator as follows:
u2f_flags u2f,user_keys
The user_keys flag enables the improved built-in U2F authenticator implementation. Users who want to test-drive the feature and are aware of the risk of using beta quality features can use this.u2f_flags
When invoked without a parameter, the command will turn of the built-in U2F authenticator feature.u2f_flags u2f
u2f_flags g2f
Enables legacy built-in U2F authenticator behavior. There is no reason to continue using this; enabling will trigger the 'Internal security key requires reset' system notification. There is no good reason to continue using the legacy implementation at this point.
Please be advised that the built-in U2F authenticator feature remains in beta status at this point, hence crosh still prints the warning message about the experimental nature of the feature and potential consequences.