[bsmartt]

linux has had some pretty bad bugs as well. "North Korea" (not sure why you threw that in? are they exploiting this specific vuln ITW?) can only drop this if they can send you packets which they'd need to be on your network to do, or for this machine to have ports open directly to the public internet, and that shouldn't be the case for my mama's laptop...

[mrinfinitiesx]

article on the NK bit for the 38193 CVE https://arstechnica.com/security/2024/08/windows-0-day-was-e...

https://msrc.microsoft.com/update-guide/vulnerability/CVE-20... - the mitre.org link in my original comment.

I pay attention to all the CVEs daily (or as much as I can). the other one is something found in IPv6 by a research group that allows root level remote code execution by exploiting IPv6 packets, but what I'm getting at is, Windows I'll be trusting, absolutely not if it's going to be playing with this 'Recall' thing.

[bsmartt]

thanks for the links. as far as i can telll 38193 is just a priv esc so they need code execution locally first. but the two exploits you linked could possibly be chained together and that would be a pretty sophisticated attack, especially when they were 0day. but still, if you are behind a router they cant just throw this at any consumer.

[mrinfinitiesx]

Could load javascript on a page and have them send outgoing crafted packets with websockets, or just have the webserver send them catered packets and let NAT send it where it has to go. It was found by a research group so it's not 'known known' but these CVEs happen every day, as do they for Linux. 0days are rare, it's our hopes research/cybsec groups find them firsthand though. I'm just having a little fun with it is all, preaching the Linux Desktop gospel.

I'm pro-privacy and I highly feel this Recall system opens up a new attack/exploit vector in new unprecedented ways that I don't even want to begin to imagine. I mean, it reads your screen and recalls everything you've ever done..

[bsmartt]

fine, but that then requires a google chrome sandbox escape or visiting an attacker controlled page, my point was just that the initial claim was rather oversimplified.

[mrinfinitiesx]

Even if patched/depracated, still a websocket to any ip-address with the packets as long as it can send the packet. Literally any chat applet.

Torrent files, pretty much anything. It's not that scary at the moment.

Browsers can do it now. It's an age old 'feature' -> https://github.com/garywill/LAN-port-scan-forbidder

uBlock apparently blocks your browser from reaching out to your LAN though, but; no 'sandbox escapes' needed, just javascript being loaded.

Our browsers could have been exploiting things behind NAT this entire time. Smart TVs, Smart watches, phones, anything pingable on your LAN.

Go here and see it in action: http://samy.pl/webscan/

[halter73]

> Our browsers could have been exploiting things behind NAT this entire time. Smart TVs, Smart watches, phones, anything pingable on your LAN.

Maybe if they’re running an HTTP server (which isn’t too uncommon for IoT devices) while allowing the attacker website via CORS (less likely). An IoT device listening for WebSocket or WebRTC connections won’t benefit from CORS, but those are relatively rare and ought to have other mitigations in place.

All your links show is the ability to scan ports, not even read the responses to the fetch() requests made to local IP addresses. That could be useful to an attacker, but a far cry from exploiting any smart device or having the ability to send “outgoing crafted packets” from the browser. You cannot even open arbitrary sockets or craft arbitrary HTTP requests.