Gandalf_The_Grey

Level 23
Verified
The Chrome team is delighted to announce the promotion of Chrome 79 to the stable channel for Windows, Mac and Linux. This will roll out over the coming days/weeks.
Chrome 79.0.3945.79 contains a number of fixes and improvements -- a list of changes is available in the log. Watch out for upcoming Chrome and Chromium blog posts about new features and big efforts delivered in 79.
Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.
This update includes 51 security fixes.
 

MalwareTips Bot

Robot
Verified
Content Creator
The Chrome team is delighted to announce the promotion of Chrome 79 to the stable channel for Windows, Mac and Linux. This will roll out over the coming days/weeks.

Chrome 79.0.3945.79 contains a number of fixes and improvements -- a list of changes is available in the log. Watch out for upcoming Chrome and Chromium blog posts about new features and big efforts delivered in 79.


This update includes 51 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.


[$20000][1025067] Critical CVE-2019-13725: Use after free in Bluetooth. Reported by Gengming Liu, Jianyu Chen at Tencent Keen Security Lab on 2019-11-15
[$TBD][1027152] Critical CVE-2019-13726: Heap buffer overflow in password manager. Reported by Sergei Glazunov of Google Project Zero on 2019-11-21
[$10000][944619] High CVE-2019-13727: Insufficient policy enforcement in WebSockets. Reported by @piochu on 2019-03-21
[$7500][1024758] High CVE-2019-13728: Out of bounds write in V8. Reported by Rong Jian and Guang Gong of Alpha Lab, Qihoo 360 on 2019-11-14
[$5000][1025489] High CVE-2019-13729: Use after free in WebSockets. Reported by Zhe Jin(金哲),Luyao Liu(刘路遥) from Chengdu Security Response Center of Qihoo 360 Technology Co. Ltd on 2019-11-16
[$5000][1028862] High CVE-2019-13730: Type Confusion in V8. Reported by Wen Xu of SSLab, Georgia Tech on 2019-11-27
[$TBD][1023817] High CVE-2019-13732: Use after free in WebAudio. Reported by Sergei Glazunov of Google Project Zero on 2019-11-12
[$TBD][1025466] High CVE-2019-13734: Out of bounds write in SQLite. Reported by "Team 0x34567a61" @Xbalien29 @leonwxqian on 2019-11-16
[$TBD][1025468] High CVE-2019-13735: Out of bounds write in V8. Reported by Gengming Liu and Zhen Feng from Tencent Keen Lab on 2019-11-16
[$TBD][1028863] High CVE-2019-13764: Type Confusion in V8. Reported by Wen Xu of SSLab, Georgia Tech on 2019-11-26
[$7500][1020899] Medium CVE-2019-13736: Integer overflow in PDFium. Reported by Anonymous on 2019-11-03
[$5000][1013882] Medium CVE-2019-13737: Insufficient policy enforcement in autocomplete. Reported by Mark Amery on 2019-10-12
[$5000][1017441] Medium CVE-2019-13738: Insufficient policy enforcement in navigation. Reported by Johnathan Norman and Daniel Clark of Microsoft Edge Team on 2019-10-23
[$3000][824715] Medium CVE-2019-13739: Incorrect security UI in Omnibox. Reported by xisigr of Tencent's Xuanwu Lab on 2018-03-22
[$2000][1005596] Medium CVE-2019-13740: Incorrect security UI in sharing. Reported by Khalil Zhani on 2019-09-19
[$2000][1011950] Medium CVE-2019-13741: Insufficient validation of untrusted input in Blink. Reported by Michał Bentkowski of Securitum on 2019-10-07
[$2000][1017564] Medium CVE-2019-13742: Incorrect security UI in Omnibox. Reported by Khalil Zhani on 2019-10-24
[$1000][754304] Medium CVE-2019-13743: Incorrect security UI in external protocol handling. Reported by Zhiyang Zeng of Tencent security platform department on 2017-08-10
[$1000][853670] Medium CVE-2019-13744: Insufficient policy enforcement in cookies. Reported by Prakash (@1lastBr3ath) on 2018-06-18
[$500][990867] Medium CVE-2019-13745: Insufficient policy enforcement in audio. Reported by Luan Herrera (@lbherrera_) on 2019-08-05
[$500][999932] Medium CVE-2019-13746: Insufficient policy enforcement in Omnibox. Reported by David Erceg on 2019-09-02
[$500][1018528] Medium CVE-2019-13747: Uninitialized Use in rendering. Reported by Ivan Popelyshev and André Bonatti on 2019-10-26
[$N/A][993706] Medium CVE-2019-13748: Insufficient policy enforcement in developer tools. Reported by David Erceg on 2019-08-14
[$N/A][1010765] Medium CVE-2019-13749: Incorrect security UI in Omnibox. Reported by Khalil Zhani on 2019-10-03
[$TBD][1025464] Medium CVE-2019-13750: Insufficient data validation in SQLite. Reported by "Team 0x34567a61" @Xbalien29 @leonwxqian on 2019-11-16
[$TBD][1025465] Medium CVE-2019-13751: Uninitialized Use in SQLite. Reported by "Team 0x34567a61" @Xbalien29 @leonwxqian on 2019-11-16
[$TBD][1025470] Medium CVE-2019-13752: Out of bounds read in SQLite. Reported by Wenxiang Qian of Tencent Blade Team on 2019-11-16
[$TBD][1025471] Medium CVE-2019-13753: Out of bounds read in SQLite. Reported by Wenxiang Qian of Tencent Blade Team on 2019-11-16
[$500][442579] Low CVE-2019-13754: Insufficient policy enforcement in extensions. Reported by Cody Crews on 2014-12-16
[$500][696208] Low CVE-2019-13755: Insufficient policy enforcement in extensions. Reported by Masato Kinugawa on 2017-02-25
[$500][708595] Low CVE-2019-13756: Incorrect security UI in printing. Reported by Khalil Zhani on 2017-04-05
[$500][884693] Low CVE-2019-13757: Incorrect security UI in Omnibox. Reported by Khalil Zhani on 2018-09-17
[$500][979441] Low CVE-2019-13758: Insufficient policy enforcement in navigation. Reported by Khalil Zhani on 2019-06-28
[$N/A][901789] Low CVE-2019-13759: Incorrect security UI in interstitials. Reported by Wenxu Wu (@ma7h1as) of Tencent Security Xuanwu Lab on 2018-11-05
[$N/A][1002687] Low CVE-2019-13761: Incorrect security UI in Omnibox. Reported by Khalil Zhani on 2019-09-10
[$N/A][1004212] Low CVE-2019-13762: Insufficient policy enforcement in downloads. Reported by csanuragjain (@csanuragjain) on 2019-09-16
[$TBD][1011600] Low CVE-2019-13763: Insufficient policy enforcement in payments. Reported by weiwangpp93 on 2019-10-05



We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.

As usual, our ongoing internal security work was responsible for a wide range of fixes:
  • [1032080] Various fixes from internal audits, fuzzing and other initiatives

Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL.


Interested in switching release channels? Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
 

Gandalf_The_Grey

Level 23
Verified
“Aw Snap!” Crash Makes a Comeback in Chrome 79:
What to do?
Before releasing Chrome 79, Google updated the support page dedicated to this issue, notifying users that the code integrity verification would be back in the browser.
The developer also provides a new set of recommendations to avoid the "Aw Snap!" crash if it emerges with the latest Chrome:
  1. Ensure all installed anti-virus software is up to date.
  2. Reach out to your anti-virus software provider to understand their compatibility timelines.
  3. If you are able, please reply to this thread and share the name and version number of the anti-virus software you use on your computer.
If updating the incompatible software is not possible right now, the obvious alternative is to start Chrome with Code Integrity turned off. This can be done by launching the browser with the following argument:
--disable-features=RendererCodeIntegrity
One user with SEP on the system said that they solved the problem by running Chrome in Windows 8 compatibility mode.
 

DDE_Server

Level 11
Verified
Version 79 of Chrome is out, and it promises to do a better job of protecting you against phishing sites and credential stuffing attacks.
Since 2017, Chrome has protected users against phishing by checking the sites you enter your Google credentials into against a list of known phishing sites. It keeps these as part of its Safe Browsing initiative. Google synchronises its list of bad sites with the browser every 30 minutes, but because sites change so quickly, that means users might fall victim to new sites that had come online just minutes earlier.
Chrome 79, released on Tuesday 10 December, now performs that phishing protection in real-time, even for users with the synchronisation feature turned off. The company says this will protect users in 30% more cases. The protection has also been extended to include all the passwords stored in the Chrome password manager rather than just Google accounts. You can turn it on by enabling the ‘Make searches and browsing better’ option in Chrome.
The browser also now includes some other protections. It will now show you more clearly which profile the browser is currently using, which is handy for those sharing a browser and using different profiles. There’s also a feature that Google has been testing out for months: a built-in check for hacked passwords during site logins.
The feature began as a Chrome extension called Password Checkup that warned users their login credentials had been breached. Released in February 2019, it found that 1.5% of all web logins were using breached credentials, according to a Google survey released in August this year. That fuelled Google’s next move, in which it folded the feature directly into Chrome’s password manager. The service still didn’t check your credentials against hacked logins whenever you logged into a website. Instead, it would run the passwords you’d stored in the password manager service periodically to see if it found a match.
The version of Password Checkup integrated into Chrome 79 goes a step further. Now, it runs the check whenever you log into a site. Google is at pains to avoid any suggestion of creepiness or spying as part of this move, so it’s been pretty clever about how it performs the check. It wants to be clear that it doesn’t get to see your login credentials.
When you log into a website, Chrome will now send a hashed copy of your login credentials to Google. A hash creates a unique and reproducible string of text using whichever data you give to it, which identifies the data without revealing it. This data is encrypted in the browser using an encryption key to which only you have access.
Google already used its own key to encrypt the list of hacked login credentials that it sniffed from various sources online. It does the same thing with the credentials that Chrome sends it, encrypting them a second time.

This double encryption is part of a technique called private set intersection with blinding. It tries to match the login credentials you entered against Google’s database of hacked usernames and passwords.
For your privacy, Google doesn’t do this matching itself. Instead, it sends a small part of its encrypted hacked credentials database back to Chrome, along with your double-encrypted login credentials (which you’ll remember have now been encrypted twice). Chrome removes the encryption it applied to your login credentials using your own key, leaving only Google’s encryption in place. It then tries to match those hashed encrypted credentials against the small subset of the database that it received from Google. If it finds one, then your credentials have been hacked.
Google knows which small subset of the database to send back because your browser also creates a hash of the username you tried to enter into the website. It sends part of that hash to Google along with the other data. Google uses that snippet of your hashed username to select the part of its database including the same snippet in the index.
It’s an ingenious system, and as long as you feel you can trust the encryption (and Google), then it looks like a good way to automate hacked password detection. It will alert you that your credentials have been pwned at the point in time when you’re most likely to do something about it – when you’re trying to log into the site.
As with all password breaches, you should change your password if Chrome does discover a match, and turn on multi-factor authentication if the hacked site makes it available, to prevent a possible attack. You should also avoid reusing passwords across multiple sites so that attackers won’t be able to unlock your other accounts with a hacked password. You can make that easier by using a password manager with a built-in password generator.
 
Last edited: