apple_badger

hmlongco said:

apple_badger said:

That's not how vulnerability chaining doesn't work. Safari is already downloaded and running on your device and CVE-2022-32893 potentially gives an attacker the ability to use Safari to leverage CVE-2022-32894. 

Yet AFAIK Safari doesn't ship with a malicious code exploit embedded within it. Not to mention that WebKit is also sandboxed pretty heavily. I'll grant that the possibility of chaining one exploit into another... but only in the sense that ANYTHING is possible. It's possible that the Earth could explode in the next 0.2 seconds. It is, however, not probable.

Safari doesn't have to ship with malicious code; CVE-2022-32893  allows an attacker to inject their own code into the Safari process and execute it. At this point sandboxing should kick in and limit the damage, but CVE-2022-32894 allows the possibility of that attacker's code being run with kernel privileges, at which point it's game over. This is not an unlikely event; it's an absolutely textbook example of an exploit chain. 

lkrupp said:

Remember, people, this is the former 'Facebook security chief’. Facebook and security are mutually exclusionary terms. It’s like trying to put a square peg into a round hole. It ain’t happening.

Stamos is *highly* respected in the information security community. Speaking as someone who's job title includes the words chief, information, security, and officer, when he says something I almost always find it worth considering and never dismiss it outright based on where he's worked. For what it's worth, by all account his time at Facebook wasn't a harmonious one. 

He's guest hosted the Risky Business security podcast numerous times. If you want to get a sense of the guy, I recommend listening to those episodes. 

I'm going to respectfully disagree here. Speaking as someone who heads up Information security for an organization, this may not be as quite bad as it gets (it won't kill your dog), but it's darn close. A remote code execution flaw in webkit paired with the ability to execute arbitrary code with kernel privileges is really, really, *really* bad. 

That headline, while strictly true, is a touch misleading. Microsoft is suggesting a move to Android or iOS, something that's mentioned, but the headline makes it look as if they're recommending only iOS. *I* recommend only iOS, but Microsoft seems to be less convicted :P 

hmlongco said:

apple_badger said:

CVE-2022-32893 is an arbitrary code execution bug in Webkit. 
CVE-2022-32894 is an arbitrary code execution with kernel privileges bug.

Both have been addressed in this update. 

https://support.apple.com/en-us/HT213413

Okay, The kernel issue is related to an application running on macOS. i.e. The user would have to download, enable, and run an app with an exploit. The arbitrary code execution bug in Webkit is worrisome, but isn't related to the kernel privileges issue. 

It's not, "A remote code execution flaw in webkit paired with the ability to execute arbitrary code with kernel privileges is really, really, *really* bad. " They're not "paired", they're two distinct issues.

That's not how vulnerability chaining doesn't work. Safari is already downloaded and running on your device and CVE-2022-32893 potentially gives an attacker the ability to use Safari to leverage CVE-2022-32894. 

cpsro said:

apple_badger said:

I'm going to respectfully disagree here. Speaking as someone who heads up Information security for an organization, this may not be as quite bad as it gets (it won't kill your dog), but it's darn close. A remote code execution flaw in webkit paired with the ability to execute arbitrary code with kernel privileges is really, really, *really* bad. 

Even if an Apple user doesn't manually update, the system will automatically update within a week of release.

Only if automatic updates are enabled, unless something has changed since the last time I checked (which is a possibility). Though, automatic updates are on by default. 

(I'm not being critical of Apple here; I'm disagreeing with this story's downplaying of the importance of this update. It's *very* important, and it's very important to update sooner rather than later)

Edit to add: The time from publication of a vulnerability to attempted exploitation is now measured in hours, not days or weeks. When something like this is made public then its value as something to be used in targeted attacks against only high value targets is effectively zero. There's no reason for bad actors to exercise restraint at this point. 

hal301 said:

One other difference, although not clearly mentioned by Apple, is that the LG monitor has an internal power supply - the power cord plugs directly into the back of the monitor.  The Studio Display most likely uses the same (or at least very similar) external brick that the 24" iMac uses. So one more small box on the floor.

The Studio Display does not use an external power brick. It's just a power cord from the back of the display to a standard wall plug. 

"Where a VPN comes in is that it could act as a major route on the information superhighway that is the internet. While your normal ISP-based route for your packets could take a congested or slow path to the destination, a VPN could help you bypass the slow bits. 

If you're playing on far-away servers, such as those in a different continent to where you are, it could be better to use a VPN server. Using one that exits on that continent will reduce the number of hops required."

This is either completely wrong or phrased oddly. If, by some weird chance it ever happens that using a VPN improves anything to do with latency, it's some odd accident that almost certainly won't happen on a regular basis. 

I just taped a piece of cardboard to the front of my iPad and tried to close the MagicKeyboard... and it closed just fine. I suspect that this is a nonissue that's on its way to becoming the next something-gate. 

anome said:

Upping the security isn't that much of an improvement if it isn't end-to-end. The whole architecture of Zoom is basically a man-in-the-middle vulnerability.

I keep seeing people decry its lack of end-to-end encryption. Their initial instance that they provide it was stupid, as was how long they held on to that claim before eventually dropping it, but beyond that I do not understand the shortcoming. There is no video conference service that offers end-to-end encryption at scale for large, multipoint sessions. How could that possibly work? That's a genuine question, not rhetorical. I cannot fathom how multiple video sessions could be combined into a single session without a central server that decrypts the individual sessions, combines them, and then sends the combined stream to each percipient. The alternative would be fully meshed connections of each endpoint to all the others but that can't scale out.