
Apple releases OS X Mavericks 10.9.2 with SSL fix - davidbarker
http://9to5mac.com/2014/02/25/apple-releases-os-x-mavericks-10-9-2-with-facetime-audio-contact-blocking-mail-fixes/
======
ecmendenhall
This bug was pretty serious. I'd better be extra careful and install and
verify this myself.

Oh, good: there's a standalone installer available
([http://support.apple.com/kb/DL1726](http://support.apple.com/kb/DL1726)).
But the download is served over HTTP. Maybe I can just try the same URL with
HTTPS:

    
    
      $ curl --head https://support.apple.com/downloads/DL1726/en_US/OSXUpdCombo10.9.2.dmg
      HTTP/1.1 302 Moved Temporarily
      Server: Apache/2.2.24 (Unix)
      Location: http://download.info.apple.com/Mac_OS_X/031-3279.20140225.Zzasf/OSXUpdCombo10.9.2.dmg
    

Nope. Well, at least I can verify the SHA1 sum displayed on the download page.
Wait, no, that was served over HTTP, too.

Okay, I'll follow Apple's instructions for checking the certificate
fingerprint in the installer
([http://support.apple.com/kb/ht5044](http://support.apple.com/kb/ht5044)).
But that page (Last modified November 2011) displays _a different fingerprint_
(9C864771 vs FA02790F)...and that fingerprint was _also_ served over HTTP.

 _Gives up and opens the App Store._

~~~
pilif
The packages themselves are signed: Mount the .dmg file and use pkgutil
--check-signature /path/to/Installer.pkg to check whether the package is
signed by a valid CA (if you want to be totally sure, do this check on a
machine running 10.8 or earlier)

~~~
isomorphic
FWIW, I did this for the combo update. The SHA1 checksum on the Apple page,
c06a63982b522e43997a05cedc04b0bdb1a10207, matches the file, and pkgutil
reports

    
    
       Package "OSXUpdCombo10.9.2.pkg":
    
       Status: signed Apple Software
    
       Certificate Chain:
        1. Software Update
           SHA1 fingerprint: 1E 34 E3 91 C6 44 37 DD 24 BE 57 B1 66 7B 2F DA 09 76 E1 FD
           -----------------------------------------------------------------------------
    
        2. Apple Software Update Certification Authority
           SHA1 fingerprint: FA 02 79 0F CE 9D 93 00 89 C8 C2 51 0B BC 50 B4 85 8E 6F BF
           -----------------------------------------------------------------------------
    
        3. Apple Root CA
           SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60

------
e1ven
Forgive me, but I'm not really sure why this is getting so much attention.

It's certainly a bad bug, and it ought to have been caught. But it feels like
this would be much harder to exploit than many other bugs which have had far
less hoopla.

As I understand, this SSL bug makes it rather trivial to perform MITM attacks
against apps which use the default system SSL libs.

That's certainly a problem, but most people are using trustworthy ISPs (at
least in this sense). Comcast seems unlikely to try to steal your bank
password, and Verizon is unlikely to try to harvest your HN cookies.

It seems like this primarily affects people connecting to untrustworthy
access-points, such as Coffee Shops, or Airport Wifi - While that's certainly
something that needs to be fixed, it seems far less crucial than remote-code-
execution [1], or many other bugs we see regularly.

I'm sure I'm missing something here, can someone help me understand? Is it
just the "Ick" factor of having something you thought was encrypted actually
being fairly open?

I don't understand why this is getting more attention that other (seemingly)
more dangerous exploits.

[1] -
[http://msisac.cisecurity.org/advisories/2013/2013-088.cfm](http://msisac.cisecurity.org/advisories/2013/2013-088.cfm)

~~~
ambrop7
It's getting attention because:

\- It's an easy to spot bug,

\- in the most critical part of the code,

\- of a fundamental security library,

\- and it's been there for a long time, nobody knows how many systems have
already been compromised due to it.

With this bug, Apple's library isn't actually a SSL implementation. It does
not perform the most essential part of a SSL implementation - verifying that
the peer possesses the private key it claims to posses.

> it seems far less crucial than remote-code-execution

> I don't understand why this is getting more attention that other (seemingly)
> more dangerous exploits.

Because it's the foundation for a heap of applications and services that were
believed to be secure due to use of SSL. If you consider those, this is worse
than any bug in any application. It's not just one application with a critical
vulnerability - effectively, it's half (or whatmany) of all OSX and iOS apps
with a critical vulnerability. All you need to do is go browse the net in a
coffee shop, and some stranger can easily do things like:

\- Pwn your box (MITM the auto update). Actually with this he can do all of
the latter too.

\- Steal your money (MITM your bank connection).

\- Steam your online accounts, including email.

It's not "just a bug". Yes, everyone makes mistakes, we're all human. But it's
completely unacceptable that those mistakes get unnoticed and into production
code of such a critical component, and deployed to millions of users.

> That's certainly a problem, but most people are using trustworthy ISPs

Your argument seems to be that it's not a big issue if the security is totally
broke since we don't need security in the first place.

~~~
eslaught
> "It's not "just a bug". Yes, everyone makes mistakes, we're all human. But
> it's completely unacceptable that those mistakes get unnoticed and into
> production code of such a critical component, and deployed to millions of
> users."

This is not a reasonable argument. At Pwn2Own each year, how many browsers
have vulnerabilities that allow remote code execution? All of them. How many
of these vulnerabilities are zero-days? A significant number of those. This
happens every single year. Even the advanced protections in e.g. Chrome don't
stop new vulnerabilities from being found on a regular basis. And all of these
products are deployed to millions of users.

You could complain about Apple's response to this bug, and that might be a
reasonable complaint to make. At least Google patches bugs quickly when they
surface at Pwn2Own. But that's different from claiming the bugs shouldn't have
existed (or should have been caught before making it into production). Bugs
are fundamentally hard to find, and it's not really getting any easier.

~~~
aethr
While it's true that almost all software has bugs that can result in exploits,
I think most of the exploits used in Pwn2Own are typically the result of
complex interactions between subsystems that are hard to predict. As software
gets more complex, the attack surface increases.

The Apple bug isn't really in that class of exploit. It's a simple
coding/merge error, and it's actually a regression from previously working
code. One of the things that worries me is that this bug would have been
caught so easily with basic unit tests.

    
    
        Test 1: Make connection to server with a valid SSL certificate [PASSED]
        Test 2: Make connection to a server with an invalid SSL certificate [FAILED]
    

Are we meant to think that Apple's build process doesn't use unit testing?
Seems unlikely. Or perhaps this component didn't warrant an extensive test
suite? I hope not! Not really sure what the explanation is.

I mean, I certainly can't claim that all my code is run through extensive
tests before every deploy, but then I'm not working on the security tools that
underpin an entire operating system.

~~~
phlo
In this case, the very test you're describing would not have worked. For a
better writeup, see agl's post[1] on the matter. The basic gist of it: On
affected systems, the server may use _any_ combination of private key and
certificate. Most SSL libraries used on the server side will make sure the
moduli of cert and private key match (and abort if this isn't the case). Unit
testing would thus require a server with some modifications to its SSL library
(OpenSSL, in most cases).

What would have caught the bug: automatic code indentation or any sort of
compile-time warnings about dead code.

[1]
[https://www.imperialviolet.org/2014/02/22/applebug.html](https://www.imperialviolet.org/2014/02/22/applebug.html)

~~~
aethr
I see what you mean, the amount of work and foresight needed to predict the
bug and write a test for it does seem unrealistic in that light. Hingdsight is
20/20, etc.

------
sneak
Ahh, so they probably had to restart the QA on the whole release a few days
ago (including FaceTime Audio and associated features) after adding the TLS
fix at the last minute.

It makes a bit more sense why they'd make us wait a few days, now.

~~~
outside1234
Its totally unacceptable. Even Microsoft does patches of this severity in less
than 24 hours.

I suspect what this points to is that Apple doesn't have automated testing and
they need a bunch of old school "hands on keyboards testers" to run a test
case list that takes 4 days.

~~~
georgebarnett
The parent 'suspects' and doesn't actually know. It's not 'totally
unacceptable' either. It's over a weekend and it's a set of trade offs about
cutting a release made by a bunch of smart engineers who were probably very
tired (last week for them has probably sucked) and they've just pulled a long
weekend to get this out the door.

If you find this 'totally unacceptable', my suggestion would be to either go
join them and help them improve the situation or to move to another OS.
Bitching on the internet merely indicates how little experience you have with
the trade offs that need to be made when pushing latge volumes of software.

~~~
sneak
> my suggestion would be to either go join them and help them improve the
> situation

Uhh no, we're customers. I don't find it unacceptable but if I did, it's
within my rights to say so without "help[ing] them" as I pay the Apple Tax
happily and repeatedly.

------
dmboyd
This should really have been a separate fix & installed without user
interaction. Instead this is 450 Megs & requires a restart. It'll take days
for it to get out to those at risk.

~~~
sneak
> This should really have been a separate fix & installed without user
> interaction

Considering it needs to update the TLS support on the rescue partition too,
doing it outside of single-user mode is probably not a good idea.

You're nitpicking, it seems.

~~~
Angostura
Actually, that's a good point - I suspect testing the wacky double update
could have added a day or so to QA

------
jtokoph
The fun thing to think about is whether or not you can guarantee that the
update you receive is actually from Apple and not someone sending you a fake
via MITM.

Sure, they show a SHA1 on this page:
[http://support.apple.com/kb/DL1726](http://support.apple.com/kb/DL1726) but
that could be MITM'd as well.

~~~
msbarnett
Updates are signed and the OS will refuse to run them if signature
verification fails, so unless your MITM has Apple's signing key that wouldn't
work.

(And no, this bug didn't break client-side signed package verification.)

~~~
ambrop7
Unless your box has already been pwnd and the update installer has been
modified to not install that update in the way it was meant to be.

~~~
msbarnett
Yes, if we assume you're already fucked, then we can conclude that there is
nothing you can do to verify anything and that you are fucked, because we have
assumed our conclusion. SHA1s and MD5s are equally pointless in this case
because you've already assumed you're fucked, so it should all be assumed to
be lying to you.

If, however, we don't engage in circular reasoning and we assume your box
isn't currently in the possession of the Russian mafia or (insert preferred
APT here), then how can one be reasonably confident that the update one
receives through the updater is legitimately the one Apple is distributing?

Because it is signed and the code-signing verification was not broken by this
bug.

~~~
stcredzero
_If, however, we don 't engage in circular reasoning_

I agree with the point you're making, but you can also turn this idea around,
after which it serves to highlight how insanely inadequate our current tools
and infrastructure are from a security standpoint.

Basically, you can only reasonably hope to verify a patch if you're not
already owned, so you also have to assume you're not in order to verify. It's
as if there was a contagious disease that has a good chance of killing you
after a number of years, but the diagnostic tests can only be counted on to
work if you don't have the disease in the first place. So then why would
anyone ever bother getting tested? Our current situation is that
uncomfortable.

~~~
msbarnett
> Basically, you can only reasonably hope to verify a patch if you're not
> already owned, so you also have to assume you're not in order to verify.
> It's as if there was a contagious disease that has a good chance of killing
> you after a number of years, but the diagnostic tests can only be counted on
> to work if you don't have the disease in the first place. So then why would
> anyone ever bother getting tested? Our current situation is that
> uncomfortable.

Being owned is less like having a virus and more like having schizophrenia.
You can't ever expect to self-verify yourself, because if you're suffering
from it, everything you're perceiving is being filtered through a compromised
and untrustworthy system.

You have to trust some third-party that you believe to not be similarly
compromised to do the verification for you.

~~~
stcredzero
_You have to trust some third-party that you believe to not be similarly
compromised to do the verification for you._

Which effectively means that most people won't bother, unless a "trusted third
party" is built into their machine.

But that has huge potential problems of its own.

------
pje
> The release notes, however, do not make mention of the SSL security bug that
> was squashed on iOS late last week.

~~~
meepmorp
If anyone from Apple is reading and can influence this - could you convince
whomever needs to be convinced that you ought to have less vague/shitty
release notes, particularly wrt issues like this?

~~~
praseodym
They cover security issues in a separate announcement (listed on
[http://support.apple.com/kb/HT1222](http://support.apple.com/kb/HT1222)), but
only a few hours after the update has been released. I do think high-impact
security issues like this SSL bug deserve a mention in the release notes as
well.

~~~
Cless
Looks like they're just trying to not make it obvious that Macs can have
security problems. I don't think many regular users (who probably think Macs
are invincible) are going to actively look for security announcements about
their invincible Mac. And when they look at the release notes, many of them
won't be convinced to stop what they're doing and install some unnecessary
updates.

(Not trashing Mac, I am a Mac user.)

~~~
rdl
I wonder if their hope is everything transitions to something like iOS before
this is falsified in a widespread way on OSX in public.

In corporate settings with desktop management, Macs are actually a huge pain
to deal with; Windows maybe starts from crappier defaults but there's a much
more mature industry around locking it down.

~~~
jordanthoms
Hence why you want to be the odd one out with a Mac at Corporates: IT leaves
you alone and you can manage it yourself.

~~~
davexunit
If you really want IT to leave you alone you need a GNU/Linux machine.

------
nextstep
>> • Adds call waiting support for FaceTime audio and video calls

Cool. Someday I'd like to be able to leave a FaceTime voicemail message if the
receiver declines the FaceTime call.

~~~
gburt
Surely this would be facemail, not voicemail. :)

------
rmoriz
Damn, I was close… :-)

[http://i.imgur.com/vKnXhJ8.png](http://i.imgur.com/vKnXhJ8.png)

~~~
cpr
Isn't yours just a manifestation of the general TLS bug? Or does it differ
somehow?

~~~
rmoriz
No, it's just a bug of the SecureTransport backend in curl [1]. I thought
Apple maintains the backend as nobody else uses it (homebrew curl uses
OpenSSL) and that's why I've submitted the issue to Apple instead to the curl
maintainer.

So maybe it brought some eyes on the "gotofail" but that's just speculation…

Thanks anonymous Apple guy :)

[1]
[https://github.com/bagder/curl/pull/93/files](https://github.com/bagder/curl/pull/93/files)

------
SmileyKeith
I cant believe they don't even mention the SSL bug in this. That's just
insulting.

~~~
avtar
It's mentioned in the last line here
[http://support.apple.com/kb/HT6114](http://support.apple.com/kb/HT6114) And
yeah, that's kind of bizarre.

~~~
SmileyKeith
Nice call. Yea very strange. Seems like the most important thing in this
update. It should at least be at the top of the bug fix list.

------
flatdeviant
Apple has also changed the behavior of the power button on notebooks.
Previously, pressing the button made the Mac instantly go to sleep. Now, just
pressing it doesn't do anything. You can still hold the power button for 3
seconds to get the usual "Are you sure you want to shut down your computer
now?" dialog box.

Awesome for those of us using FileVault who have to enter their login password
each time they wake up their computer.

~~~
acdha
This changed back when 10.9 was released:

[http://support.apple.com/kb/HT5869](http://support.apple.com/kb/HT5869)

~~~
randomdata
The parent is correct. In 10.9, pressing the power button put the computer to
sleep, replacing the dialog prompt shown in your link. As of 10.9.2, simply
pressing it does nothing at all.

------
guid
Interesting: After the update, ocspd downloaded roughly 40MB of ...
certificate revocation lists?

ocspd /usr/sbin/ocspd Total: 196 B sent, 45.8 MB received Outgoing to
devimages.apple.com (92.122.207.101), Port http (80), Protocol TCP (6), 196 B
sent, 45.8 MB received

~~~
cerberusss
I think that's not related to the SSL/TLS bug, but instead to the curl problem
that also came with the update to 10.9.2. This is the description from Apple's
security mailing list:

"curl Available for: OS X Mavericks 10.9 and 10.9.1 Impact: An attacker with a
privileged network position may intercept user credentials or other sensitive
information Description: When using curl to connect to an HTTPS URL containing
an IP address, the IP address was not validated against the certificate. This
issue does not affect systems prior to OS X Mavericks v10.9. CVE-ID
CVE-2014-1263 : Roland Moriz of Moriz GmbH"

------
millerm
To all those who say "it was so easy to spot", congrats on finding the flaw
and letting us all know first thing. /s

------
brown9-2
What about non-Mavericks versions of OS X?

~~~
Jare
10.8 and earlier are not vulnerable.

------
gwu78
A compelling way to get holdouts to upgrade iOS/OSX. Get those iPhone 4 folks
who are content with iOS 6.x to install iOS 7.x.

God only knows what incompetence and disregard for user privacy and sanity
awaits in these "new" versions. What are they adding that we really need? Oh,
the ability to use SSL PKI. Yeah, I guess you have to upgrade.

Why isn't HN discussing the effects this screw up has on email? Email is
bigger than the web, belive it or not.

And most of the world appears to use webmail.

With this "bug" HTTPS for your webmail is futile.

You have no way to know you are connecting to the real googlemail, yahoomail,
hotmail, etc.

The "authentication" functions of SSL need to be made an compilation option,
not a default.

It's obvious almost no knows or cares how to use SSL's PKI mechanism properly.

SSL's encryption capabilities have been useful, but using SSL to do server
authentication causes more problems than it solves.

History has shown it's just not easy enough to use.

SSH can do authentication without PKI. Alas, it is embedded into a program
that only nerds use.

I'm using the authentication framework in CurveCP. I'm working on making it
very easy to use.

~~~
ralfd
Don't be a ignorant. Together with 7.0.6 there was also a security update to
iOS 6.1.6.

[http://support.apple.com/kb/HT6146](http://support.apple.com/kb/HT6146)

------
plg
confirmed here as well, it's fixed

[https://gotofail.com](https://gotofail.com)

------
chmars
In 10.9.2. Apple did also fix a sadly impressive number of other security-
related bugs:

[http://support.apple.com/kb/HT6150](http://support.apple.com/kb/HT6150)

------
dola
What I wonder, is if Apple can be held responsible (to some extent) for
damages that resulted due to this bug for app developers like a bank whose
customers were robbed because the bank relied on the secure connection as it
should have been provided by the Apple API. Clearly, the attacker is still the
person to have exploited the bug but I think a developer should be able to
assume that Apples security relevant API functionalities are indeed secure.

~~~
spiralpolitik
Remember that software license you clicked while installing ? Most likely it
had something like:

THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

So yeah Apple can't be held responsible. If they could then the whole free
software open source community would be in deep doo doo.

------
lelf

      PHP
      Available for:  OS X Lion v10.7.5, OS X Lion Server v10.7.5,
      OS X Mountain Lion v10.8.5, OS X Mavericks 10.9 and 10.9.1
      Impact:  Multiple vulnerabilities in PHP
      Description:  Multiple vulnerabilities existed in PHP, the most
      serious of which may have led to arbitrary code execution <…>
    

Didn't know it's in Mac OS X… But yeah, it is… /usr/bin/php

~~~
0x0
Oddly enough, the release notes states they upgraded to "5.4.22"... but
"/usr/bin/php -v" gives "5.4.24" here.

------
pivo
Hope it also fixes the "issue" where my 2013 Macbook Pro reboots when it wakes
up from sleep if there's a USB drive attached.

~~~
serge2k
Mine grey screens when I have my usb hub plugged in at startup (doesn't get to
partition selection).

Android file transfer utility stops the keyboard and touchpad from working.

~~~
lucasisola
I've got a similar USB issue. I have a SATA HDD in an External USB 3.0
enclosure. When my 2011 iMac wakes from sleep, it needs to wait for the
external drive to spin up. Major PITA.

------
jasey
_edit_ \- oh wow I just read what this fix's. Will be updating asap

I haven't upgraded to Mavericks at all yet because I'm worried that it will
break software I depend on a daily basis. Can some please confirm if upgrading
has a significant risk of breaking compatibility with things like rails, mamp,
netbeans, android studio, golang, vagrant, virtualbox, docker etc.

Thanks

------
QuiteMouse
So are they going to release this fix for Snow Leopard ? Not all of us are on
the latest and greatest hardware.

~~~
spiralpolitik
The issue only effects OS X Mavericks.

------
eik3_de
Is it possible to manually verify the code signature with Apple's built-in
public key before installing?

~~~
lotharrr
I would hope the built-in software-upgrade process does exactly that
(independent of transport-layer SSL), but I have no evidence either way.

The manual-download pages on
[http://support.apple.com/downloads/](http://support.apple.com/downloads/)
publish SHA1 sums. Unfortunately those pages aren't served over SSL. You could
download the update and compare its hash against those of your friends: at
least then you'd all be installing the same thing (preventing narrowly-
targetted attacks).

~~~
sitkack
The Apple site
[http://support.apple.com/kb/DL1726](http://support.apple.com/kb/DL1726)
reports

    
    
      c06a63982b522e43997a05cedc04b0bdb1a10207
    

which matches my download using `shasum -a OSXUpdCombo10.9.2.dmg`

------
calinet6
Does it fix the networking stack also? Please dear god let it fix the
networking stack.
([https://discussions.apple.com/thread/5551686?start=0&tstart=...](https://discussions.apple.com/thread/5551686?start=0&tstart=0))

~~~
bdash
Yes, this should be fixed in 10.9.2.

~~~
calinet6
Any proof or reference? I'd prefer not to wait about 23 days for my server to
explode.

------
0x0
Finally.

Unfortunately we'll probably always be in the dark about the HOW, WHO and WHY.
:(

~~~
scott_karana
Of course.

If it was an honest mistake, they're not going to publically throw an employee
under the bus.

If it was a malicious action from the NSA, they're not allowed to make it
public.

I suspect the only hypothetical way we'd hear about the "who" is if an
employee weakened it for his own personal gain, and criminal charges were
raised.

------
cajueira
I have not read much in regards to _WHY_ this exact same bug was also found in
OSX. Can anyone shed some light on this?

Do they use the same code stack for iOS and OSX? This seems weird to me - even
though parts of code could be used in both operating systems, I would imagine
separate teams would be on iOS and OSX, each reviewing code bases on their
own, running unit tests and whatnot. Still, this major flaw has been present
for 2.5(?) years - all the more reason for paranoia about its presence.

Add to this, why wait so long with the OSX update? A security issue THIS
serious MUST be patched instantly and rolled out as an individual/separate
update as soon as possible, even if that means pushing back OSX 10.9.2. Or did
they need some time to introduce a new flaw somewhere? o_O

------
rdl
I'm confused -- the osx dev center doesn't have 10.9.2 at all (any build),
only the original October 10.9 release. I guess that happens whenever they
push a new release?

~~~
nicky0
Developer preview builds are now pushed out the Mac App Store.

See the Dev center for the instructions to set it up.

------
cs02rm0
No sign of 4k@60Hz on the rMBP for the 32" Dell then?

------
joelmbell
Its fixed

------
therealmarv
Yeah. Finally they fixed this ssl bug and also important to me this annoying
webcam bug on Macbook Air for Skype and Hangouts.

------
LeoNatan25
I hope for a iOS 7.1 beta soon with this fix.

~~~
Watabou
iOS was already patched a couple of days ago with iOS 7.0.6

~~~
LeoNatan25
Yes, they fixed the 7.0.X branch, but the 7.1 beta branch is still unfixed.

------
protomyth
Well, the bugs I reported in Finder are still there and it still crashes. I am
very much missing Snow Leopard.

------
chrisBob
But will this fix the bug where my mail doesn't update for hours at a time?!!

------
jcampbell1
Just installed this. Now I get a HSTS error on github for both Chrome and
Safari.

~~~
subdigital
I do too. Did you find any more details on this?

~~~
subdigital
to fix it I had to reset my Keychain. Pain in the ass, but it was preventing
me from working.

To do this, open Keychain Access, open Preferences, and click Reset Keychain.
It will create a new login keychain and keep your old one backed up in the
keychains folder.

~~~
jcampbell1
I use digicert for my own company, and I had some old certificates in the key
chain. Deleting those solved the problem.

------
vardump
OS X Mavericks audio problems are still not fixed. Audio dropouts in Google
Chrome more often than once per second when a lot of tabs are open. Makes for
example Youtube unbearable to watch. Chrome audio worked fine in OSX 10.8 with
a lot more tabs.

Mid 2012 MBP (MacBookPro9,2).

~~~
giovannibajo1
Are you sure it's not a chrome bug? Obviously chrome updated itself many times
in the meantime. Do you see this same bug even in different contexts (eg when
using multiple applications, when doing CPU-intensive tasks and using iTunes
at the same time, etc.)?

~~~
vardump
The bug does not show up immediately with light load in Chrome (only a few
tabs open). But anything heavier, and audio dropouts start. No idea whether
it's a Chrome bug or OSX, but the problem started immediately after 10.9
update.

The issue is present after a fresh reboot with no other applications running
than Chrome.

My Chrome version is now 33.0.1750.117, which should be the current one.

iTunes and Safari audio output is always fine.

I run VMWare Fusion 6 virtual machines often, but that doesn't seem affect the
bug way or another. Also, I only installed VF6 long after updating to 10.9.

Audio in Windows or Linux Chrome running in a VF6 virtual machine is perfectly
good.

Just tested again, the issue seems to only affect Chrome playing Macromedia
Flash content. I don't have Flash player installed, only Chrome's internal
PPAPI Flash player.

------
watermarkcamera
At last fixed SSL bug at OSX Mavericks 10.9.2

------
bkmrkr
Still no handling for hidpi and dell 2815Q

------
volume
i wonder how soon a metasploit plugin will be available?

------
emocakes
took me 4 reboots and 15minutes of waiting at something do with SD cards to
get this crap installed. Even windows update works better these days.

------
johnny635
How many more backdoors will be discovered?

------
rch
I'm still not upgrading to Mavericks. I have a lot of work to do, and I
dislike being asked to upend my system on somebody else's schedule.

~~~
cpach
If you don’t run Mavericks you’re not affected by the goto fail.

~~~
rch
Yep, I know. As discussed a couple of days ago.

I think I'm just bothered by my perception that this Mavericks upgrade is
being presented as a fix for an OS X security issue, rather than just offering
a patch to Mavericks users.

~~~
spiralpolitik
My guess is that the time to get the 10.9.2 release out the door was less then
it would have taken to get a seperate patch done.

