Recently, Linux has been rising in desktop popularity in no small part to the work on WINE and Proton. But for some, the year of the Linux desktop is not enough, and the goal is now for the year of the Linux phone. To that end, an Android Linux translation layer called Android Translation Layer (we never said developers were good at naming) has emerged for those running Linux on their phones.

Android Translation Layer (ATL) is still in very early days, and likely as not, remains unpackaged on your distro of choice. Fortunately, a workaround is running an Alpine Linux container with graphics pass through via a tool like Distrobox or Toolbox. Because of the Alpine derived mobile distribution postmarketOS, ATL is packaged in the Alpine repos.

In many ways, running Android apps on Linux is much easier then Windows apps. Because Android apps are architecture independent, hardware emulation is unnecessary. With such similar kernels, on paper at least, Android software should run with minimal effort on Linux. Most of what ATL provides is a Linux/Android hardware abstraction layer glue to ensure Android system calls make their way to the Linux kernel.

Of course, there is a lot more to running Android apps, and the team is working to implement the countless Android system APIs in ATL. For now, older Android apps such as Angry Birds have the best support. Much like WINE, ATL will likely devolve into a game of wack-a-mole where developers implement fresh translation code as new APIs emerge and app updates break. Still, WINE is a wildly successful project, and we hope to see ATL grow likewise!

If you want to get your Android phone to talk to Linux, make sure to check out this hack next!

hackaday.com/2025/09/10/a-look…

SAP ha reso disponibili degli aggiornamenti per la sicurezza Martedì, con l’obiettivo di risolvere varie vulnerabilità. Tra queste vulnerabilità, ve ne sono tre particolarmente critiche che si verificano all’interno dell’ambiente SAP Netweaver.

Queste problematiche di sicurezza potrebbero consentire l’esecuzione di codice a scelta dell’attaccante nonché il caricamento di file specifici senza vincoli particolari.

Tutto questo dopo che un difetto critico di sicurezza presente in SAP S/4HANA, recentemente sanato dall’azienda (CVE-2025-42957, con un punteggio CVSS pari a 9,9), è stato oggetto di uno sfruttamento attivo; questa notizia giunge subito dopo che Pathlock e SecurityBridge hanno portato a conoscenza del problema, con le patch che sono state rilasciate soltanto alcuni giorni più tardi.

Un’ulteriore vulnerabilità di alta criticità è stata eliminata da SAP all’interno della piattaforma SAP S/4HANA (assegnata come CVE-2025-42916, con un punteggio CVSS pari a 8,1), la quale avrebbe potuto essere sfruttata da un soggetto malintenzionato dotato di elevate autorizzazioni di accesso ai report ABAP per cancellare i dati contenuti in tabelle di database a sua scelta, a condizione che queste non fossero coperte da un gruppo di autorizzazioni dedicato.

Di seguito sono elencate le vulnerabilità:

• CVE-2025-42944 (punteggio CVSS: 10.0) – Una vulnerabilità di deserializzazione in SAP NetWeaver che potrebbe consentire a un aggressore non autenticato di inviare un payload dannoso a una porta aperta tramite il modulo RMI-P4 , con conseguente esecuzione di comandi del sistema operativo
• CVE-2025-42922 (punteggio CVSS: 9,9) – Una vulnerabilità nelle operazioni sui file non sicure in SAP NetWeaver AS Java che potrebbe consentire a un aggressore autenticato come utente non amministratore di caricare un file arbitrario
• CVE-2025-42958 (punteggio CVSS: 9,1) – Una vulnerabilità di controllo dell’autenticazione mancante nell’applicazione SAP NetWeaver su IBM i-series che potrebbe consentire a utenti non autorizzati con privilegi elevati di leggere, modificare o eliminare informazioni sensibili, nonché di accedere a funzionalità amministrative o privilegiate

“Il CVE-2025-42944 consente a un aggressore non autenticato di eseguire comandi arbitrari del sistema operativo inviando un payload dannoso a una porta aperta”, ha affermato Onapsis. “Un exploit riuscito può portare alla compromissione completa dell’applicazione. Come soluzione temporanea, i clienti dovrebbero aggiungere il filtraggio delle porte P4 a livello ICM per impedire a host sconosciuti di connettersi alla porta P4.”

Per garantire una difesa massima, risulta cruciale che gli utenti procedano all’installazione degli aggiornamenti richiesti con la massima tempestività, sottolinea SAP, nonostante non esistano evidenze che gli exploit recentemente resi noti siano stati effettivamente utilizzati per scopi malevoli.

L'articolo 10 su 10! SAP rilascia patch di sicurezza per vulnerabilità critiche in Netweaver proviene da il blog della sicurezza informatica.

Ci stiamo avviando a passi da gigante vero l’uroboro, ovvero il serpente che mangia la sua stessa coda. Ne avevamo parlato qualche settimana fa che il traffico umano su internet è in calo vertiginoso rispetto a quello dei bot che ad oggi supera il 50% del traffico totale.

Sam Altman, CEO di OpenAI e azionista di Reddit, ha confessato che i feed di “AI Twitter” e “AI Reddit” gli appaiono sempre più innaturali, al punto da diventare per lui un vero campanello d’allarme.

Il segnale è arrivato dal subreddit r/Claudecode, dove negli ultimi giorni molti utenti hanno dichiarato di essere passati a Codex, il servizio di programmazione di OpenAI lanciato a maggio per competere con Claude Code di Anthropic. Le ondate di post quasi identici hanno fatto pensare ad Altman di trovarsi davanti a contenuti generati da bot, pur sapendo che la crescita di Codex è reale e che dietro c’è anche un’autentica dinamica comunitaria.

Analizzando la sua percezione, Altman ha individuato diversi fattori: linguaggio sempre più simile a quello dei modelli di AI, comunità “sempre online” che si muovono in massa con toni uniformi, oscillazioni emotive tipiche dell’hype — dal pessimismo totale all’euforia — e l’amplificazione data dagli algoritmi di raccomandazione e dalla monetizzazione delle piattaforme. A questo si aggiungono campagne occulte orchestrate dalle aziende e, naturalmente, la presenza di veri bot.

Il paradosso è evidente: i modelli di OpenAI sono stati addestrati proprio su contenuti di Reddit e progettati per sembrare umani, imitando persino segni di punteggiatura come i trattini lunghi. Altman, che di Reddit è stato anche membro del consiglio di amministrazione ed è tuttora azionista, si trova così a confrontarsi con un ecosistema dove autenticità e automazione si confondono.

I dubbi sono aumentati dopo il lancio di GPT-5, quando le community di OpenAI su Reddit e X hanno criticato il modello, accusandolo di consumare troppi crediti e di non completare alcune attività. Altman ha risposto con una sessione AMA su r/GPT, riconoscendo i problemi e promettendo correzioni. Ma la fiducia della community non è tornata ai livelli precedenti. Questo solleva una domanda cruciale: dove finisce la reazione genuina degli utenti e dove inizia il riflesso del testo generato automaticamente?

Il fenomeno dei bot è ormai sistemico. Secondo Imperva, nel 2024 più della metà del traffico internet non proveniva da esseri umani, e una parte rilevante era costituita da sistemi basati su LLM. Anche Grok, l’AI di X, stima la presenza di centinaia di milioni di account bot, pur senza fornire dettagli. In questo scenario, alcuni osservatori leggono le parole di Altman come un indizio di un possibile “social network di OpenAI”, di cui nel 2025 sarebbero già emersi i primi test, anche se non è chiaro se il progetto diventerà realtà né se riuscirà davvero a garantire uno spazio libero dai bot.

La ricerca scientifica, intanto, mostra che persino comunità composte interamente da bot tendono a riprodurre dinamiche umane: uno studio dell’Università di Amsterdam ha dimostrato che queste reti finiscono per dividersi in clan e camere di risonanza. La linea tra scrittura umana e scrittura artificiale, quindi, si fa sempre più sfumata. Altman non fa che notare il sintomo di un problema più profondo: piattaforme in cui persone e modelli si imitano a vicenda finiscono per parlare con una voce sola. E distinguere l’autenticità diventa sempre più difficile, facendo crescere il prezzo della fiducia, anche quando dietro c’è una crescita reale.

L'articolo Verso L’Uroboro! Il CEO di OpenAI avverte: i social sono pieni di contenuti dei bot AI proviene da il blog della sicurezza informatica.

A fine agosto, GreyNoise ha registrato un forte aumento dell’attività di scansione mirata ai dispositivi Cisco ASA. Gli esperti avvertono che tali ondate spesso precedono la scoperta di nuove vulnerabilità nei prodotti. Questa volta, si tratta di due picchi: in entrambi i casi, gli aggressori hanno controllato massicciamente le pagine di autorizzazione ASA e l’accesso Telnet/SSH in Cisco IOS.

Il 26 agosto è stato osservato un attacco particolarmente esteso, avviato da una botnet brasiliana, che ha utilizzato circa 17.000 indirizzi univoci e ha gestito fino all’80% del traffico. In totale, sono state osservate fino a 25.000 sorgenti IP. È interessante notare che entrambe le ondate hanno utilizzato intestazioni di browser simili, mascherate da Chrome, a indicare un’infrastruttura comune.

Gli Stati Uniti erano l’obiettivo principale, ma anche Regno Unito e Germania sono stati monitorati.

Secondo GreyNoise, circa l’80% di tali ricognizioni si traduce nella successiva scoperta di nuove problematiche di sicurezza, sebbene la correlazione statistica sia notevolmente più debole per Cisco rispetto ad altri produttori. Ciononostante, tali indicatori consentono agli amministratori di rafforzare in anticipo le proprie difese.

In alcuni casi, questi potrebbero essere tentativi falliti di sfruttare bug già chiusi, ma una campagna su larga scala potrebbe anche essere mirata a mappare i servizi disponibili per un ulteriore sfruttamento di vulnerabilità non ancora divulgate.

Un amministratore di sistema indipendente con il nickname NadSec – Rat5ak, ha segnalato un’attività simile iniziata a fine luglio e che ha preso slancio fino al 28 agosto. Ha registrato oltre 200.000 richieste ad ASA in 20 ore con un carico uniforme di 10.000 richieste da ciascun indirizzo, il che indica una profonda automazione. Le fonti erano tre sistemi autonomi: Nybula, Cheapy-Host e Global Connectivity Solutions LLP.

Si consiglia agli amministratori di installare gli ultimi aggiornamenti di Cisco ASA il prima possibile per chiudere le falle note, abilitare l’autenticazione a più fattori per tutti gli accessi remoti e non pubblicare direttamente pagine /+CSCOE+/logon.html, Web VPN , Telnet o SSH.

In casi estremi, si consiglia di esternalizzare l’accesso tramite un concentratore VPN, un reverse proxy o un gateway con verifica aggiuntiva.

È inoltre possibile utilizzare gli indicatori di attacco pubblicati da GreyNoise e Rat5ak per bloccare le richieste sospette sul perimetro e, se necessario, abilitare il geo-blocking e la limitazione della velocità. Cisco non ha ancora rilasciato dichiarazioni in merito.

L'articolo Preludio alla compromissione: è boom sulle scansioni mirate contro Cisco ASA proviene da il blog della sicurezza informatica.

Un ricercatore di Limes Security, con lo pseudonimo f0rw4rd, ha presentato un nuovo strumento per sviluppatori e tester: tls-preloader. Si tratta di una libreria universale che consente di disabilitare completamente la verifica dei certificati TLS, semplificando il debug e l’analisi delle applicazioni con connessioni crittografate.

La soluzione è distribuita come libreria LD_PRELOAD che integra funzioni delle librerie TLS più diffuse. Funziona con OpenSSL (incluse le versioni 1.0.x, 1.1.x e 3.x), BoringSSL, LibreSSL, GnuTLS, NSS, mbedTLS, wolfSSL e può bypassare i controlli integrati in libcurl.

Gli autori sottolineano che la libreria è multipiattaforma e supporta Linux, FreeBSD, OpenBSD, NetBSD, Solaris, AIX e macOS. Durante la compilazione, le funzionalità della piattaforma di destinazione vengono automaticamente prese in considerazione e vengono applicate ottimizzazioni per la sicurezza dei thread, dai mutex pthread alle operazioni atomiche.

Usare tls-preloader è semplicissimo: basta compilare la libreria e caricarla tramite LD_PRELOAD. Dopodiché, è possibile eseguire qualsiasi programma, da curl e wget a script Python o Firefox, con il controllo dei certificati disabilitato. Per comodità, sono disponibili una modalità di debug e la possibilità di generare stack trace quando si chiamano funzioni intercettate.

In OpenSSL e nei suoi derivati, la libreria intercetta le funzioni SSL_CTX_set_verify(), e X509_verify_cert()i relativi controlli di scadenza di host e certificati. In GnuTLS, questi meccanismi vengono aggirati gnutls_certificate_verify_peers, mentre in NSS vengono utilizzati gli hook SSL_BadCertHook()e CERT_VerifyCert(). Tecniche simili vengono applicate ad altre implementazioni TLS.

Lo strumento è rivolto a sviluppatori e tester che lavorano con certificati autofirmati o scaduti e necessitano di un debug rapido. Gli autori sottolineano che l’utilizzo della libreria nei sistemi di produzione è severamente sconsigliato, poiché rimuove completamente uno degli elementi chiave della protezione HTTPS.

Tra i limiti del progetto rientrano l’impossibilità di lavorare con file binari compilati staticamente e la mancanza di supporto per i browser Chrome e Chromium, in cui BoringSSL è integrato direttamente. Inoltre, le applicazioni con un controllo rigoroso dei certificati (certificate pinning) potrebbero continuare a bloccare le connessioni.

Il progetto è open source e disponibile su GitHub .

L'articolo Presentato tls-preloader: la libreria che disabilita la verifica dei certificati TLS proviene da il blog della sicurezza informatica.

La scorsa settimana è stato scoperto che un’autorità di certificazione poco conosciuta, chiamata Fina, ha emesso 12 certificati TLS non autorizzati per 1.1.1.1 (un popolare servizio DNS di Cloudflare) tra febbraio 2024 e agosto 2025, senza l’autorizzazione dell’azienda. I certificati potrebbero essere stati utilizzati per decrittografare query crittografate tramite DNS su HTTPS e DNS su TLS.

La diffusione di certificati sospetti è diventata nota quasi per caso: un ricercatore è stato il primo a segnalarlo nella mailing list dev-security-policy di Mozilla. I certificati sono stati emessi da Fina RDC 2020, una CA che fa capo a Fina Root CA. È diventato subito chiaro che Microsoft si fidava dei certificati Fina Root CA, il che significava che anche Windows e Microsoft Edge si fidavano di loro.

I rappresentanti di Cloudflare hanno subito attirato l’attenzione sulla situazione e confermato che i certificati erano stati emessi illegalmente.

“Cloudflare non ha autorizzato Fina a emettere questi certificati. Dopo aver visto il rapporto nella mailing list sulla trasparenza dei certificati, abbiamo immediatamente avviato un’indagine e contattato Fina, Microsoft e l’organismo di vigilanza TSP di Fina, che potrebbero essere in grado di risolvere il problema revocando la fiducia in Fina o i certificati emessi erroneamente”, ha affermato Cloudflare.

Nella dichiarazione dell’azienda si sottolinea inoltre che il problema non riguarda i dati crittografati tramite WARP VPN. A loro volta, i rappresentanti di Microsoft hanno riferito di aver contattato il centro di certificazione e di aver chiesto un intervento immediato. L’azienda ha assicurato di aver già adottato misure per bloccare questi certificati.

I rappresentanti di Google, Mozilla e Apple hanno affermato che i loro browser non si sono mai fidati dei certificati Fina e che gli utenti non devono intraprendere alcuna azione. Il problema è che i certificati sono una parte fondamentale del protocollo TLS (Transport Layer Security). Contengono una chiave pubblica e informazioni sul dominio per il quale vengono emessi, mentre l’autorità di certificazione (l’organizzazione autorizzata a emettere certificati attendibili) detiene la chiave privata che verifica la validità del certificato.

La CA utilizza la propria chiave privata per firmare i certificati e i browser li verificano utilizzando chiavi pubbliche attendibili. In pratica, questo significa che chiunque possieda un certificato e la relativa chiave privata può impersonare crittograficamente il dominio per il quale è stato emesso.

Pertanto, il proprietario dei certificati di 1.1.1.1 potrebbe potenzialmente utilizzarli in attacchi man-in-the-middle, intercettando le comunicazioni tra gli utenti e il servizio DNS di Cloudflare. Di conseguenza, le terze parti in possesso di certificati 1.1.1.1 potrebbero decrittografare, visualizzare e modificare il traffico DNS di Cloudflare.

“L’ecosistema delle CA è un castello con molte porte: il fallimento di una CA può compromettere l’intero castello. Il comportamento scorretto delle CA, intenzionale o meno, rappresenta una minaccia significativa e continua per Cloudflare. Cloudflare ha contribuito a sviluppare e lanciare Certificate Transparency fin dall’inizio , il che ha portato alla scoperta di questo caso di emissione impropria di certificati”, ha affermato Cloudflare.

Verso la fine della scorsa settimana, Cloudflare ha pubblicato un rapporto dettagliato sull’incidente. Un audit condotto dall’azienda ha mostrato che il numero di certificati emessi impropriamente era 12, non i tre inizialmente segnalati. Peggio ancora, i primi erano stati emessi già a febbraio 2024.

I rappresentanti di Fina hanno commentato l’incidente in una breve e-mail, affermando che i certificati erano stati “emessi per test interni del processo di emissione dei certificati in un ambiente di produzione”.

L’autorità di certificazione ha dichiarato che si è verificato un errore durante l’emissione dei certificati di prova “a causa dell’inserimento errato degli indirizzi IP”. È stato sottolineato che, come parte della procedura standard, i certificati sono stati pubblicati nei registri di Certificate Transparency.

Fina ha assicurato che le chiavi private non hanno lasciato l’ambiente controllato dalla CA e sono state “distrutte immediatamente, prima che i certificati venissero revocati”. L‘azienda afferma che i certificati emessi in modo improprio “non hanno in alcun modo compromesso la sicurezza degli utenti o di altri sistemi”.

Tuttavia, Cloudflare ha affermato di prendere l’incidente molto seriamente, sottolineando che deve “presupporre che la chiave privata in questione esista e non sia sotto il controllo di Cloudflare”, poiché non c’è modo di verificare le affermazioni di Fina.

L’azienda riconosce che i rischi a cui sono stati esposti milioni di utenti Windows che si affidavano alla versione 1.1.1.1 sono in parte dovuti a Cloudflare. Cloudflare non ha implementato un controllo regolare dei log di Certificate Transparency che indicizzano l’emissione di ciascun certificato TLS e ha scoperto il problema troppo tardi.

“Abbiamo fallito tre volte. La prima volta, perché 1.1.1.1 è un certificato IP, ma il nostro sistema non ci ha avvisato di questi casi. La seconda volta, perché, anche se siamo stati avvisati delle emissioni di certificati come tutti i nostri clienti, non abbiamo implementato un filtraggio adeguato. Dato l’enorme numero di nomi e di emissioni che gestiamo, i controlli manuali non sono sufficienti. Infine, a causa di un monitoraggio troppo “rumoroso”, non abbiamo abilitato gli avvisi per tutti i nostri domini. Stiamo lavorando per correggere tutte e tre queste carenze”, scrive Cloudflare.

L'articolo Scoperti certificati TLS non autorizzati per 1.1.1.1, il servizio DNS di Cloudflare proviene da il blog della sicurezza informatica.

Un aggiornamento urgente per motivi di sicurezza è stato messo a disposizione da Google per il browser Chrome su sistema operativo Windows, Mac e Linux. Questa nuova versione risolve una falla critica che permetterebbe a malintenzionati di eseguire, da remoto, codice a loro discrezione.

Un potenziale aggressore è in grado di abusare di questa debolezza creando un sito web malevolo che, una volta visitato da un utente, permetterebbe all’aggressore di eseguire un codice sul sistema dell’utente stesso.

L’aggiornamento è attualmente in fase di distribuzione e sarà disponibile per tutti gli utenti nei prossimi giorni e settimane. Questa patch segue la versione iniziale di Chrome 140, che ha risolto anche diversi altri problemi di sicurezza.

Si consiglia vivamente agli utenti di aggiornare immediatamente i propri browser per proteggersi da potenziali minacce. Il canale stabile è stato aggiornato alla versione 140.0.7339.127/.128 per Windows, 140.0.7339.132/.133 per Mac e 140.0.7339.127 per Linux.

L’aggiornamento risolve due importanti falle di sicurezza, la più grave delle quali il CVE-2025-10200. Questa vulnerabilità è classificata come critica e viene descritta come un bug “Use-after-free” nel componente Serviceworker.

Un difetto di tipo use-after-free si verifica quando un programma tenta di utilizzare la memoria dopo che questa è stata deallocata, il che può causare arresti anomali, danneggiamento dei dati o, nel peggiore dei casi, esecuzione di codice arbitrario.

Il ricercatore di sicurezza Looben Yang ha segnalato questa falla critica il 22 agosto 2025. In riconoscimento della gravità della scoperta, Google ha assegnato una ricompensa di 43.000 dollari per il bug scoperto.

La seconda vulnerabilità corretta in questa versione è CVE-2025-10201, un difetto di elevata gravità identificato come “Implementazione inappropriata in Mojo”. Mojo è una raccolta di librerie runtime utilizzate per la comunicazione tra processi all’interno di Chromium, il progetto open source alla base di Chrome.

La seconda vulnerabilità è stata segnalata da Sahan Fernando e da un ricercatore anonimo il 18 agosto 2025. Ai reporter è stata assegnata una ricompensa di 30.000 dollari per le loro scoperte.

I difetti di questo componente possono essere particolarmente pericolosi in quanto possono compromettere potenzialmente la sandbox del browser, una funzionalità di sicurezza fondamentale che isola i processi per impedire che gli exploit influenzino il sistema sottostante.

Google sta distribuendo l’aggiornamento gradualmente, ma gli utenti possono verificarne manualmente la presenza e applicarlo andando su Impostazioni > Informazioni su Google Chrome.

L'articolo Aggiornamento urgente per Google Chrome: Use-after-free nel componente Serviceworker proviene da il blog della sicurezza informatica.