Thursday, February 21, 2013

Stable Channel Update

The Chrome team is excited to announce the promotion of Chrome 25 to the Stable Channel. Chrome 25.0.1364.97 for Windows and Linux, and 25.0.1364.99 for Mac contain a number of new items including:
Security fixes and rewards:

Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.
  • [$1000] [172243] High CVE-2013-0879: Memory corruption with web audio node. Credit to Atte Kettunen of OUSPG.
  • [$1000] [171951] High CVE-2013-0880: Use-after-free in database handling. Credit to Chamal de Silva.
  • [$500] [167069] Medium CVE-2013-0881: Bad read in Matroska handling. Credit to Atte Kettunen of OUSPG.
  • [$500] [165432] High CVE-2013-0882: Bad memory access with excessive SVG parameters. Credit to Renata Hodovan.
  • [$500] [142169] Medium CVE-2013-0883: Bad read in Skia. Credit to Atte Kettunen of OUSPG.
  • [172984] Low CVE-2013-0884: Inappropriate load of NaCl. Credit to Google Chrome Security Team (Chris Evans).
  • [172369] Medium CVE-2013-0885: Too many API permissions granted to web store.
  • [Mac only] [171569] Medium CVE-2013-0886: Incorrect NaCl signal handling. Credit to Mark Seaborn of the Chromium development community.
  • [171065] [170836] Low CVE-2013-0887: Developer tools process has too many permissions and places too much trust in the connected server.
  • [170666] Medium CVE-2013-0888: Out-of-bounds read in Skia. Credit to Google Chrome Security Team (Inferno).
  • [170569] Low CVE-2013-0889: Tighten user gesture check for dangerous file downloads.
  • [169973] [169966] High CVE-2013-0890: Memory safety issues across the IPC layer. Credit to Google Chrome Security Team (Chris Evans).
  • [169685] High CVE-2013-0891: Integer overflow in blob handling. Credit to Google Chrome Security Team (Jüri Aedla).
  • [169295] [168710] [166493] [165836] [165747] [164958] [164946] Medium CVE-2013-0892: Lower severity issues across the IPC layer. Credit to Google Chrome Security Team (Chris Evans).
  • [168570] Medium CVE-2013-0893: Race condition in media handling. Credit to Andrew Scherkus of the Chromium development community.
  • [168473] High CVE-2013-0894: Buffer overflow in vorbis decoding. Credit to Google Chrome Security Team (Inferno).
  • [Linux / Mac] [167840] High CVE-2013-0895: Incorrect path handling in file copying. Credit to Google Chrome Security Team (Jüri Aedla).
  • [166708] High CVE-2013-0896: Memory management issues in plug-in message handling. Credit to Google Chrome Security Team (Cris Neckar).
  • [165537] Low CVE-2013-0897: Off-by-one read in PDF. Credit to Mateusz Jurczyk, with contributions by Gynvael Coldwind, both from Google Security Team.
  • [164643] High CVE-2013-0898: Use-after-free in URL handling. Credit to Alexander Potapenko of the Chromium development community.
  • [160480] Low CVE-2013-0899: Integer overflow in Opus handling. Credit to Google Chrome Security Team (Jüri Aedla).
  • [152442] Medium CVE-2013-0900: Race condition in ICU. Credit to Google Chrome Security Team (Inferno).
We’ve also resolved a high severity security issue by disabling MathML in this release. The WebKit MathML implementation isn’t quite ready for prime time yet but we are excited to enable it again in a future release once the security issues have been addressed.

Many of the above bugs were detected using AddressSanitizer.

We’d also like to thank Christian Holler, miaubiz and Atte Kettunen for working with us during the development cycle and preventing security regressions from ever reaching the stable channel. Rewards were issued.

A full list of changes in this build is available in the SVN revision log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

Jason Kersey
Google Chrome

28 comments:

Roman Galperin said...
This comment has been removed by the author.
SemiSane said...

You have definitely forgotten to upload Linux packages:

http://dl.google.com/linux/chrome/rpm/stable/i386/google-chrome-25.0.1364.97-183676.i386.rpm

404. That’s an error.

That’s all we know.

antage said...

Err http://dl.google.com/linux/chrome/deb/ stable/main google-chrome-stable amd64 25.0.1364.97-r183676
404 Not Found [IP: 173.194.47.167 80]
Failed to fetch http://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_25.0.1364.97-r183676_amd64.deb 404 Not Found [IP: 173.194.47.167 80]

Cito said...

Err http://dl.google.com/linux/chrome/deb/ stable/main google-chrome-stable i386 25.0.1364.97-r183676
404 Not Found [IP: 173.194.37.37 80]

Jason Kersey said...

Sorry for the trouble, should be all fixed now.

Victor said...

I'm a little confused as to whether Chrome can only protect users against malicious Javascript through disabling Java plugins all together OR Google has actually updated to the latest Java?

Please clarify.

Unknown said...

Still no thumbnails in the last 5 Chrome beta updates.

Pro Deo eτ Paτria said...

Every time so many security flaws have been fixed... It seems Chrome is still strainer. I'd recommend using it only for fun...

Dima Pursanov said...

Something is breaking the layout here. Some links on my website go down ~5px after page refresh! In all other browsers this works as in previous chrome stable release: after the refresh all links stay on their positions.

grunwald said...

Regarding "JavaScript Web Speech API support" it seems to be limited to the recognition part of the API. The synthesis part is not visible/ covered.

Octavio Schroeder said...
This comment has been removed by the author.
Toutatis said...

It seems that for Linux the 64 bit .rpm is still version 24.0.1312.70.....


João Ramos said...
This comment has been removed by the author.
João Ramos said...

Ever since I updated to chrome version 25 last night, whenever I choose a tab or whenever I insert a website it just sends me to that website and 5 seconds later I'm on the "google.com" page! And afterwards it just keeps refreshing the "google.com" page! I can't even browse for mroe than 5 seconds at a time! Please fix this!! I'm runnning your latest chrome version so far on Windows 7 64 bits also up-to-date. I don't even know how am I going to update chrome now since it does the same when I try to access my settings!

Alex Keeling said...

I'm running slackware, so I download the rpm and convert it to a tgz. I've just done that with the 64 bit rpm version, but it's only chrome 24, not 25. Has anyone else been able to download version 25?

Jo said...

@João

Try clearing your cache and cookies.

João Ramos said...

@Jo

I reinstalled and it works as usual now! Thanks anyway :)

C.home said...

Beginning yesterday, Chrome is now requesting access to passwords in keychain. I know this happened back in June when Google changing the signing certificate. Any reason it is happening now?

I don't use Chrome to store passwords and that option is not selected in settings.

Paska said...

@Dima Pursanov: It seems that there's an issue with floating in this version, see bug https://code.google.com/p/chromium/issues/detail?id=178137

I'm having the same issue (and i'm not the reporter). Seems this was solved by giving the wrapper of elements with a float, a min-height.

Jem said...
This comment has been removed by the author.
Jem said...

There seems to be a problem with the version of Flash in this release (and the current Chrome Beta) interacting with the webcam. On a site that accesses the webcam (MS Lifecam in my case), although the cam works the quality is dreadful and the webcam software for controlling the cam does not start up. This is now a fresh install of Chrome Stable with the cam software / driver also re-installed. Tested in IE9 and FF and works fine. Site I used to test: http://testwebcam.com/

Windows 7 Pro x64

Laza said...

Dear Google,

You have added back "ontouch..." events to devices not supporting touch events at all. This has been happened in the past and you chose to revert back to the good old method of skipping touch handlers on devices that have no support for it.

Though I see the logic behind this move, in the past millions of webpages were created with ("ontouchend" in document) as feature detection. I know this is not the proper method, but there was no other way to do it. (There's still no way to detect this feature cross-browser.) Even Modernizr.touch detects the presence of this event handler rather than the actual touch capability. Web developers do need this information to be able to optimize their user's experience, and they are not curious about the browser can add an otherwise unusable event handler.

With this move millions of webpages will become unusable, like our client's pages, who get the wrong behavior attached to their page controls, rendering them nearly unusable. I'd suggest you to postpone this move until there will be a standard way and cross-browser support to detect the touch capabilities.

Thank you,
Laszlo Molnar

Ben Wilda said...

Anyone else having issues with this latest release and GPU acceleration? My problems are similar to what is described in the comments for the 24.x stable release (web pages do not load at all). We've found two workarounds. One is to go to about:flags and disable GPU compositing and Threaded compositing, which breaks the flash plugin. The other is to add the command switches "--disable-gpu --disable-software-rasterizer" to the chrome shortcut. This appears to fix everything, but is annoying for obvious reasons when you're supporting an organization with several hundred chrome users. Anyone have any suggestions?

Daniel Meschiany said...
This comment has been removed by the author.
Daniel Meschiany said...

Dear Googlers,
Some of my objects which using webkits, stopped working.
on other browsers, they still work fine.

Is there any work around? am i the only one experiencing it?

rgrds.

Melanie Reed said...

Since I updated to Chrome 25 I've had constant issue loading gmail. And today Chrome threw Kernal_mode_exception_not_handled. From the mini dump file: KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: bf8488d7, The address that the exception occurred at
Arg3: ec90dac4, Trap Frame
Arg4: 00000000

TRAP_FRAME: ec90dac4 -- (.trap 0xffffffffec90dac4)
ErrCode = 00000000
eax=e1c9ac00 ebx=00000000 ecx=8629f0d0 edx=e37d96c8 esi=ec90db60 edi=00000000
eip=bf8488d7 esp=ec90db38 ebp=ec90db48 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
win32k!PFEOBJ::vFreepfdg+0x28:
bf8488d7 8b4f38 mov ecx,dword ptr [edi+38h] ds:0023:00000038=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x8E

PROCESS_NAME: chrome.exe

LAST_CONTROL_TRANSFER: from bf8489b6 to bf8488d7

When will this be fixed?!

John Inverrary said...
This comment has been removed by a blog administrator.
John Inverrary said...
This comment has been removed by a blog administrator.