The big news this week was that OpenSSH has an unauthorized Remote Code Execution exploit. Or more precisely, it had one that was fixed in 2006, that was unintentionally re-introduced in version 8.5p1 from 2021. The flaw is a signal handler race condition, where async-unsafe code gets called from within the SIGALARM handler. What does that mean?

To understand, we have to dive into the world of Linux signal handling. Signals are sent by the operating system, to individual processes, to notify the process of a state change. For example SIGHUP, or SIGnal HangUP, originally indicated the disconnect of the terminal’s serial line where a program was running. SIGALRM is the SIGnal ALaRM, which indicates that a timer has expired.

What’s interesting about signal handling in Unix is how it interrupts program execution. The OS has complete control over execution scheduling, so in response to a signal, the scheduler pauses execution and immediately handles the signal. If no signal handler function is defined, that means a default handler provided by the OS. But if the handler is set, that function is immediately run. And here’s the dangerous part. Program execution can be anywhere in the program, when it gets paused, the signal handler run, and then execution continues. From Andries Brouwer in The Linux Kernel:

It is difficult to do interesting things in a signal handler, because the process can be interrupted in an arbitrary place, data structures can be in arbitrary state, etc. The three most common things to do in a signal handler are (i) set a flag variable and return immediately, and (ii) (messy) throw away all the program was doing, and restart at some convenient point, perhaps the main command loop or so, and (iii) clean up and exit.

The term async-signal-safe describes functions that have predictable behavior even when called from a signal handler, with execution paused at an arbitrary state. How can such a function be unsafe? Let’s consider the async-signal-unsafe free(). Here, sections of memory are marked free, and then pointers to that memory are added to the table of free memory. If program execution is interrupted between these points, we have an undefined state where memory is both free, and still allocated. A second call to free() during execution pause will corrupt the free memory data structure, as the code is not intended to be called in this reentrant manner.

So back to the OpenSSH flaw. The SSH daemon sets a timer when a new connection comes in, and if the authentication hasn’t completed, the SIGALRM signal is generated when the timer expires. The problem is that this signal handler uses the syslog() system call, which is not an async-safe function, due to inclusion of malloc() and free() system calls. The trick is start an SSH connection, wait for the timeout, and send the last bytes of a public-key packet just before the timeout signal fires. If the public-key handling function just happens to be at the correct point in a malloc() call, when the SIGALRM handler reenters malloc(), the heap is corrupted. This corruption overwrites a function pointer. Replace the pointer with an address where the incoming key material was stored, and suddenly we have shellcode execution.

There are several problems with turing this into a functional exploit. The first is that it’s a race condition, requiring very tight timing to split program execution in just the right spot. The randomness of network timing makes this a high hurdle. Next, all major distros use Address Space Layout Randomization (ASLR), which should make that pointer overwrite very difficult. It turns out, also on all the major distros, ASLR is somewhat broken. OK, on 32-bit installs, it’s completely broken. On the Debian system tested, there’s literally a single bit of ASLR in play for the glibc library. It can be located at one of two possible memory locations.

Assuming the default settings for max SSH connections and LoginGraceTime, it takes an average of 3-4 hours to win the race condition to trigger the bug, and then there’s a 50% chance of guessing the correct address on the first try. That seems to put the average time at five and a quarter hours to crack a 32-bit Debian machine. A 64-bit machine does have ASLR that works a bit better. A working exploit had not been demonstrated as of when the vulnerability write-up was published, but the authors suggest it could be achieved in the ballpark of a week of attacking.

So what systems should we really worry about? The regression was introduced in 8.5p1, and fixed in 9.8p1. That means Debian 11, RHEL 8, and their derivatives are in the clear, as they ship older OpenSSH versions. Debian 12 and RHEL 9 are in trouble, though both of those distros now have updates available that fix the issue. If you’re on one of those distros, particularly the 32-bit version, it’s time to update OpenSSH and restart the service. You can check the OpenSSH version by running nc -w1 localhost 22 -i 1, to see if you’re possibly vulnerable.

Polyfill

The Polyfill service was once a useful tool, to pull JavaScript functions in to emulate newer browser features in browsers that weren’t quite up to the task. This worked by including the polyfill JS script from polyfill.io. The problem is that the Funnull company acquired the polyfill domain and Github account, and began serving malicious scripts instead of the legitimate polyfill function.

The list of domains and companies caught in this supply chain attack is pretty extensive, with nearly 400,000 still trying to link to the domain as of July 3rd. We say “trying”, as providers have taken note of Sansec’s report, breaking the story. Google has blocked associated domains out of advertising, Cloudflare is rewriting calls to polyfill to a clean cache, and Namecheap has blackholed the domain, putting an end to the attack. It’s a reminder that just because a domain is trustworthy now, it may not be in the future. Be careful where you link to.

Pack It Up

We’re no strangers to disagreement over CVE severity drama. There can be a desire to make a found vulnerability seem severe, and occasionally this results in a wild exaggeration of the impact of an issue. Case in point, the node-ip project has an issue, CVE-2023-42282, that originally scored a CVSS of 9.8. The node-IP author has taken the stance that it’s not a vulnerability at all, since it requires an untrusted input to be passed into node-ip, and then used for an authorization check. It seems to be a reasonable objection — if an attacker can manipulate the source IP address in this way, the source IP is untrustworthy, regardless of this issue in node-ip.

The maintainer, [Fedor] made the call to simply archive the node-ip project in response to the seemingly bogus CVE, and unending stream of unintentional harassment over the issue. Auditing tools starting alerting developers about the issue, and they started pinging the project. With seemingly no way to fight back against the report, archiving the project seemed like the best solution. However, the bug has been fixed, and Github has reduced the severity to “low” in their advisory. As a result, [Fedora] did announce that the project is coming back, and indeed it is again an active project on Github.

Bits and Bytes

[sam4k] found a remote Use After Free (UAF) in the Linux Transparent Inter Process Communication (TIPC) service, that may be exploitable to achieve RCE. This one is sort of a toy vulnerability, found while preparing a talk on bug hunting in the Linux kernel. It’s also not a protocol that’s even built in to the kernel by default, so the potential fallout here is quite low. The problem is fragmentation handling, as the error handling misses a check for the last fragment buffer, and tries to free it twice. It was fixed this May, in Kernel version 6.8.

CocaoPods is a dependency manager for Swift/Objective-C projects, and it had a trio of severe problems. The most interesting was the result of a migration, where many packages lost their connection to the correct maintainer account. Using the CocaoPods API and a maintainer email address, it was possible for arbitrary users to claim those packages and make changes. This and a couple other issues were fixed late last year.

I rappresentanti di Roskomnadzor hanno riferito ai media che, su richiesta del dipartimento, Apple ha bloccato 25 applicazioni di vari servizi VPN nell’App Store della Federazione Russa.

“Dal 1 marzo 2024, la Russia ha vietato la diffusione online di informazioni che pubblicizzano o rendono popolari mezzi per aggirare il blocco dell’accesso a contenuti illegali. Secondo i requisiti di Roskomnadzor, Apple ha bloccato 25 applicazioni mobili di servizi VPN situate nell’App Store russo”, ha riferito il servizio stampa RKN.

L’informazione sulla rimozione dall’App Store russo è già stata confermata dagli sviluppatori di Le VPN e Red Shield VPN. Apple ha inviato loro una lettera e li ha invitati a contattare gli stessi rappresentanti di Roskomnadzor per risolvere il problema.

Oltre a Red Shield VPN e Le VPN, anche Proton VPN e NordVPN sono stati rimossi dall’App Store russo, riferisce sul suo canale Telegram il vicepresidente del comitato per la politica dell’informazione della Duma di Stato, Anton Gorelkin .

“Apple è una delle poche aziende americane che si sforza di rispettare la legislazione russa e di mantenere un dialogo con l’autorità di regolamentazione. Sono sicuro che questa posizione sia dettata dal desiderio di tornare ufficialmente sul mercato russo a lungo termine. Nel frattempo deve mantenere la sua posizione e i suoi rapporti d’affari”, scrive Gorelkin.

Secondo quanto riportato dai media tra le applicazioni cancellate figurano anche Planet VPN, Hidemy.Name VPN e PIA VPN. Roskomnadzor non ha ancora segnalato i nomi di altri servizi VPN bloccati nell’App Store.

Ricordiamo che gli sviluppatori dei browser Google, Opera e Firefox hanno precedentemente ricevuto requisiti simili per rimuovere le estensioni VPN da Roskomnadzor .

A metà giugno i rappresentanti di Mozilla hanno bloccato il download di diverse estensioni VPN per gli utenti russi. Poi l’organizzazione ha spiegato che ciò era dovuto alle “richieste persistenti” di Roskomnadzor. Ma in seguito, dopo aver valutato il panorama legislativo in Russia e i possibili rischi per la comunità e i dipendenti, Firefox ha ripristinato l’accesso al download delle estensioni bloccate.

L'articolo Muri Digitali In Costruzione. La Russia fa bloccare ad Apple le APP di VPN sull’App Store proviene da il blog della sicurezza informatica.

The Commission might let general purpose AI providers draft their own codes of practice, whereas it also accused Meta of anticompetitive behaviour under the DMA.

euractiv.com/section/digital/n…

The look, the feel, the sound — there are few things more satisfying in this world than a nice switch. If you’re putting together a device that you plan on using frequently, outfitting it with high-quality switches is one of those things that’s worth the extra cost and effort.

So we understand completely why [STR-Alorman] went to such great lengths to get the aftermarket seat heaters he purchased working with the gorgeous switches Toyota used in the 2006 4Runner. That might not sound like the kind of thing that would involve reverse engineering hardware, creating a custom PCB, or writing a bit of code to tie it all together. But of course, when working on even a halfway modern automobile, it seems nothing is ever easy.

The process started with opening up the original Toyota switches and figuring out how they work. The six-pin units have a lot going on internally, with a toggle, a rheostat, and multiple lights packed into each one. Toyota has some pretty good documentation, but it still took some practical testing to distill it down into something a bit more manageable. The resulting KiCad symbol for the switch helps explain what’s happening inside, and [STR-Alorman] has provided a chart that attributes each detent on the knob with the measured resistance.

But understanding how the switches worked was only half the battle. The aftermarket seat heaters were only designed to work with simple toggles, so [STR-Alorman] had to develop a controller that could interface with the Toyota switches and convince the heaters to produce the desired result. The custom PCB hosts a Teensy 3.2 that reads the information from both the left and right seat switches, and uses that to control a pair of beefy MOSFETs. An interesting note here is the use of very slow pulse-width modulation (PWM) used to flip the state of the MOSFET due to the thermal inertia of the heater modules.

We love the effort [STR-Alorman] put into documenting this project, going as far as providing the Toyota part numbers for the switches and the appropriate center-console panel with the appropriate openings to accept them. It’s an excellent resource if you happen to own a 4Runner from this era, and a fascinating read for the rest of us.

È stato scoperto un problema pericoloso nell’applicazione ChatGPT per macOS rilasciata di recente: tutte le chat degli utenti erano archiviate sul computer in formato testo non crittografato. Cioè, un utente malintenzionato o un malware che riuscisse ad accedere al sistema potrebbe facilmente leggere tutte le conversazioni dell’utente con ChatGPT.

Il problema è stato scoperto dallo specialista in sicurezza informatica Pedro José Pereira Vieito. Sottolinea che qualsiasi altra applicazione avrebbe potuto accedere a questi file e studiare tutte le conversazioni dell’utente con l’intelligenza artificiale, probabilmente raccogliendone molte informazioni utili.

Il ricercatore ha chiaramente dimostrato che una potenziale applicazione dannosa può facilmente leggere le chat della vittima. Inoltre, i registri delle conversazioni con ChatGPT possono essere trovati manualmente sul computer e quindi visualizzati semplicemente rinominando il file.

Lo specialista ha spiegato di aver scoperto il bug perché si è interessato al motivo per cui OpenAI ha rifiutato di utilizzare la sandbox e ha deciso di verificare dove erano archiviati i dati dell’applicazione. Il fatto è che OpenAI distribuisce l’applicazione ChatGPT per macOS solo attraverso il suo sito web. Ciò significa che non è necessario seguire i requisiti sandboxing di Apple, che si applicano ai programmi distribuiti tramite il Mac App Store.

I giornalisti di The Verge hanno contattato OpenAI e hanno informato l’azienda del problema, dopodiché gli sviluppatori hanno rilasciato una patch che crittografava le chat. I giornalisti e Pereira Vieito confermano che dopo aver installato questo aggiornamento era effettivamente impossibile leggere le chat.

“Siamo a conoscenza di questo problema e abbiamo rilasciato una nuova versione dell’applicazione che crittografa queste conversazioni”, ha commentato OpenAI. “Ci impegniamo a fornire un’esperienza utente fluida mantenendo al tempo stesso elevati standard di sicurezza man mano che la nostra tecnologia si evolve”.

L'articolo Sicurezza, questa sconosciuta! Chat-GPT per macOS memorizza in chiaro le chat proviene da il blog della sicurezza informatica.

Un sistema di commercio illegale di pesticidi e fertilizzanti contraffatti e vietati, potenzialmente pericolosi per la salute dei consumatori, è stato fermato dalle autorità rumene e italiane.
#Eurojust ed #Europol hanno favorito la costituzione e supportato la squadra investigativa comune formata da Forze di Poliza dei due Stati (#JIT). Nel corso di una serie di azioni in entrambi i paesi sono state raccolte prove di frode su larga scala, falsificazione ed evasione fiscale e un sospettato è stato arrestato.
Il commercio di tutte le sostanze è stato vietato nell'Unione europea (#UE) perché potrebbero essere pericolose per gli utilizzatori e i consumatori in quanto contengono dosi elevate di sostanze attive.
I sospettati importavano illegalmente i prodotti dalla Cina e da Singapore, ma li vendevano come fertilizzanti e pesticidi bio o organici, utilizzando etichette false. I sospettati vendevano anche prodotti contraffatti fingendo che fossero prodotti biologici legittimi.
Tra febbraio e maggio 2023, le autorità doganali rumene hanno individuato tre spedizioni sospette provenienti da paesi terzi. Successivi controlli da parte delle autorità fitosanitarie hanno confermato che si trattava di prodotti contraffatti o vietati, utilizzando etichette falsificate. Ulteriori indagini e perquisizioni in #Romania hanno dimostrato che dietro le attività illegali c'era un gruppo criminale organizzato, composto da cittadini rumeni e italiani che hanno rilevato aziende esistenti in Romania o registrato nuove società commerciali per la vendita dei prodotti in Italia. A questo scopo sono stati utilizzati moduli di dichiarazione falsificati.
L'Autorità giudiziaria italiana ha raccolto numerose prove sulla destinazione al mercato interno delle merci illegalmente introdotte in Romania e ha individuato gli indagati che avevano favorito il traffico illecito di prodotti agricoli provenienti dall'Italia.
Su richiesta delle autorità coinvolte, all’inizio di quest’anno Eurojust ha contribuito alla creazione e al finanziamento di una squadra #SIC .
Durante le attività operative, Europol ha inviato un esperto sul campo per effettuare un controllo incrociato delle informazioni operative in tempo reale e fornire agli esperti eventuali orientamenti e supporto tecnico. Questo sostegno ha portato a una serie di azioni coordinate in Romania e Italia, durante le quali sono state perquisite dieci località tra Arad, Bucarest, Verona e Napoli, raccogliendo ulteriori prove dei crimini.
Nel corso delle attività, l'Autorità Giudiziaria rumena ha arrestato anche uno degli indagati.
Le operazioni sono state effettuate da:
- Romania: Direzione per le indagini sulla criminalità organizzata e sul terrorismo, Ufficio territoriale di Costanza; Direzione delle operazioni speciali (DOS); Brigata per la lotta alla criminalità organizzata – Servizio dei porti marittimi per la lotta alla criminalità organizzata; Uffici doganali di frontiera Constanta e Constanta Sud
- Italia: Procura della Repubblica di Verona; #NAS #ArmadeiCarabinieri Padova; #Guardiadifinanza Verona