Muse-export en Avast-driver maken agent- en endpointgrenzen tastbaar

Een onderzoeker zegt dat Meta’s Muse-assistent een archief van zijn sessieomgeving naar Google Drive exporteerde, inclusief interne runtimebestanden en logs; een container escape is niet aangetoond. Daarnaast beschrijft nieuw onderzoek hoe een fout in een Avast-kerneldriver tot lokale privilege-escalatie kon leiden, al zou een recente Windows-mitigatie de beschreven exploitroute blokkeren.

Muse-export is vooral een grensprobleem tussen agent en sessieomgeving

De auteur van een technisch verslag schrijft dat hij Muse vroeg de bestanden die de assistent kon zien te archiveren en naar zijn Google Drive te sturen. Hij ontving naar eigen zeggen circa 2,7 GB gecomprimeerd — 6,8 GB uitgepakt — met onder meer Ubuntu-bestanden, interne documentatie, integratiecode, agentlogs en SSH-sleutelbestanden uit de Linux-omgeving die aan zijn sessie was toegewezen.

De relevantie zit niet alleen in de mogelijk gevoelige bestanden, maar in het exportpad: een agent met toegang tot een brede werkomgeving én een gekoppelde bestemming kan die omgeving via een gewone conversatie exfiltreren. De auteur zegt het archief, de sleutels en sessielogs niet te publiceren. Hij stelt ook expliciet géén container escape te hebben bewezen en niet te weten of de gevonden sleutels actief waren. Volgens het verslag markeerde Meta de bug-bountymelding als ‘Not Applicable’; de beschikbare context bevat geen onafhankelijke reactie of technische weerlegging van Meta.

Voor agentplatforms is dit een aansporing om de exportgrens even hard te ontwerpen als de sandbox: geef een agent alleen projectbestanden die hij nodig heeft, scheid runtimegeheimen van de werkruimte, laat bulkexport expliciet bevestigen en log welke bestanden een connector daadwerkelijk verlaat. Dat zijn ontwerpmaatregelen, geen conclusie dat Muse buiten de sessiecontainer kon komen. Oorspronkelijk verslag · Reddit-discussie

Avast-kerneldriver liet volgens onderzoekers lokale escalatie toe

Onderzoekers van S.A.F.E. beschrijven CVE-2025-13032, een double-fetchfout in een Avast-kerneldriver. Volgens hun analyse kan een lokaal proces een lengteveld tussen de allocatie en een kopie wijzigen, zodat een pool-overflow ontstaat. Zij demonstreren vervolgens op een destijds actuele Windows 11-opstelling een route naar willekeurig kernellezen en -schrijven, en daarmee lokale privilege-escalatie.

De praktische les is vooral dat endpointsecurity zelf hoog-privilege aanvalsoppervlak toevoegt: een fout in zo’n driver is niet vergelijkbaar met een fout in een gewone gebruikersapp. Tegelijk is dit geen reden om uit de losse pols beveiligingssoftware uit te schakelen. De onderzoekers schrijven dat recente Windows-kernel- en driveraccessors de door hen beschreven exploittechniek mitigeren. De beschikbare context maakt niet duidelijk welke Avast-versies zijn gerepareerd, welke Windows-builds precies onder die beperking vallen of of er alternatieve exploitpaden zijn.

Inventariseer daarom Avast-versie, Windows-updates en endpointbeleid via de normale leverancier- en beheerkanalen, en behandel de HN-discussie niet als patchadvies. Technisch verslag · HN-discussie

R9V deelt projector-VRAM met vision en houdt meer marge over

R9V, de gespecialiseerde ROCm-runtime voor Qwen3.8 Flash Next op twee Radeon AI PRO R9700-kaarten, meldt in v0.4.3 en v0.4.4 een concrete verbetering aan zijn experimentele CED-pad voor approximate long-prompt prefill. De CED-projector en vision-encoder delen nu één VRAM-regio, omdat beeldprompts geen CED gebruiken. Volgens de makers haalt de referentiehost daardoor bij de eerste kwalificatie meer vrije VRAM dan voorheen, terwijl beeldverwerking beschikbaar blijft.

Dat is een inhoudelijke vervolgstap na de einde-dagupdate van gisteren, die de initiële prefillversnelling en kwaliteitsruil behandelde. De documentatie vermeldt voor de standaardmodus nog steeds ongeveer 1,5× snellere prefill rond 13K tokens en ongeveer 1,8× vanaf 32K, maar ook circa 1,051× perplexity op prompts die lange context nodig hebben. De kwaliteitsmodus zou minder kwaliteit verliezen, tegen een kleinere snelheidswinst en extra host-RAM.

Dit maakt de route bruikbaarder op precies de geteste dual-R9700-machine, niet algemeen bewezen. R9V blijft experimenteel, vereist de specifieke hardwareopstelling en meet de winst zelf. Ook gebruikt een aangeboden profiel een model zonder refusals; de documentatie waarschuwt dat dit lokaal gebonden blijft tenzij de gebruiker het zelf blootstelt. Test dus prefill én taakuitkomst met CED aan en uit, en gebruik geen ongeremde modelendpoint als gedeelde dienst. R9V-documentatie en changelog · Reddit-discussie

systemd v262 verankert extra TPM-meetregisters anders

Een technische uitleg over NvPCRs beschrijft waarom systemd naast de schaarse gewone TPM-PCRs extra, PCR-achtige registers in TPM-NV-geheugen gebruikt. Dat biedt ruimte om onvoorspelbare gebeurtenissen — bijvoorbeeld loginactiviteit — meetbaar te houden voor remote attestation zonder secrets te breken die aan een voorspelbare boottoestand zijn gebonden.

Het nieuwe element is de herwerkte verankering in systemd v262. De auteur schrijft dat het eerdere ontwerp sinds v259 leunde op een willekeurig geheim dat tegen PCR 11 was geseald en op schijf stond. Een aanvaller met voldoende lokale macht kon dat volgens de uitleg vervangen, of via een ander OS de verwachte PCR-waarden reproduceren en het geheim terughalen. V262 zou het NvPCR-ontwerp daarom anders verankeren. Voor beheerders die TPM-gebonden diskontsleuteling, credentials of attestation gebruiken is vooral de upgrade- en dreigingsmodelvraag relevant: neem NV-registers niet aan als vanzelf onveranderlijk alleen omdat ze PCR-achtig werken.

De opgeslagen artikeltekst is afgekapt; deze samenvatting blijft daarom bij de beschreven aanleiding en ontwerpwijziging en is geen volledige implementatie-audit. Technische uitleg · Lobsters-discussie

Britse iCloud-gebruikers houden volgens analyse verschillende ADP-status

Een analyse beschrijft hoe Apple in februari 2025 stopte met het aanbieden van Advanced Data Protection (ADP) aan nieuwe Britse gebruikers, terwijl gebruikers die ADP eerder inschakelden de extra end-to-end-encryptie voorlopig behouden. Daardoor hebben twee Britse iCloud-gebruikers met verder vergelijkbare apparatuur volgens de auteur niet dezelfde beschikbare encryptie-instelling voor onder meer backups, Foto’s en iCloud Drive.

De post koppelt die situatie aan een gemelde Britse Technical Capability Notice en aan latere juridische stappen: Apple zou in juli een nieuwe klacht bij het Investigatory Powers Tribunal hebben ingediend en in september hebben gevraagd de beperkingen op openbare bevestiging van de notice op te heffen. Dat is voor Europese software- en privacypraktijk relevant omdat productbeschikbaarheid, sleutelbeheer en wettelijk toezicht zo per jurisdictie kunnen uiteenlopen — ook zonder een expliciete technische backdoor in de app.

De kernfeiten over de vermeende notice en procedure zijn in dit materiaal grotendeels gereconstrueerd uit berichtgeving en een opiniërende analyse; de notice zelf is niet openbaar. Ook maakt de discussie duidelijk dat standaard iCloud-versleuteling en end-to-end-versleuteling verschillende herstel- en dreigingsruilen hebben. Behandel dit dus als een reden om de actuele ADP-status en dataherstelopties voor een eigen Britse organisatie of gebruiker te controleren, niet als bewijs dat alle iCloud-data onversleuteld is. Analyse · HN-discussie

Verder nog

• Jev-reviewer prioriteert agentdiffs, maar niet lokaal-inhoudelijk: het nieuwe MIT-project vervangt geselecteerde diffhunks in een browserextensie door prioriteit en uitleg, zodat een reviewer eerst P0-wijzigingen ziet. De lokale server blijft op 127.0.0.1, maar de analyse stuurt gewijzigde code en nabije context volgens de documentatie naar TypeSafe en OpenAI. Standaard worden slechts de eerste twaalf wijzigingseenheden bekeken en sleutels staan owner-only maar onversleuteld op schijf. Handig als reviewhulpmiddel, maar geen lokale code-reviewgrens of volledigheidsgarantie. Project · HN-discussie