When thinking about loops in programming languages, they often get simplified down to a conditions section and a body, but this belies the dizzying complexity that emerges when considering loop edge cases within the context of static analysis. A paper titled Misconceptions about Loops in C by [Martin Brain] and colleagues as presented to SOAP 2024 conference goes through a whole list of false assumptions when it comes to loops, including for languages other than C. Perhaps most interesting is the conclusion that these ‘edge cases’ are in fact a lot more common than generally assumed, courtesy of how creative languages and their users can be when writing their code, with or without dragging in the meta-language of C’s preprocessor.

Assumptions like loop equivalence can fall apart when considering the CFG ( control flow graph) interpretation versus a parse tree one where the former may e.g. merge loops. There are also doozies like assuming that the loop body will always exist, that the first instruction(s) in a loop are always the entry point, and the horrors of estimating loop exits in the context of labels, inlined functions and more. Some languages have specific loop control flow features that differ from C (e.g. Python’s for/else and Ada’s loop), all of which affect a static analysis.

Ultimately, writing a good static analysis tool is hard, and there are plenty of cases where it’s likely to trip up and give an invalid result. A language which avoids ambiguity (e.g. Ada) helps immensely here, but for other languages it helps to write your code as straightforward as possible to give the static analysis tool a fighting chance, or just get really good at recognizing confused static analysis tool noises.

(Heading image: Control flow merges can create multiple loop entry
edges (Credit: Martin Brand, et al., SOAP 2024) )

Die photo of the Intel Pentium processor with standard cells highlighted in red. The edges of the chip suffered some damage when I removed the metal layers. (Credit: Ken Shirriff)
Whereas the CPUs and similar ASICs of the 1970s had their transistors laid out manually, with the move from LSI to VLSI, it became necessary to optimize the process of laying out the transistors and the metal interconnects between them. This resulted in the development of standard-cells: effectively batches of transistors with each a specific function that could be chained together. First simple and then more advanced auto-routing algorithms handled the placement and routing of these standard elements, leading to dies with easily recognizable structures under an optical microscope. Case in point an original (P54C) Intel Pentium, which [Ken Shirriff] took an in-depth look at.

Using a by now almost unimaginably large 600 nm process, the individual elements of these standard cells including their PMOS and NMOS components within the BiCMOS process can be readily identified and their structure reverse-engineered. What’s interesting about BiCMOS compared to CMOS is that the former allows for the use of bipolar junction transistors, which offer a range of speed, gain and output impedance advantages that are beneficial for some part of a CPU compared to CMOS. Over time BiCMOS’ advantages became less pronounced and was eventually abandoned.

All in all, this glimpse at the internals of a Pentium processor provides a fascinating snapshot of high-end Intel semiconductor prowess in the early 1990s.

(Top image: A D flip-flop in the Pentium. Credit: [Ken Shirriff] )

Cars have had DRM-like measures for longer than you might think. Go back to the 1990s, and coded cassette decks were a common way to stop thieves being able to use stolen stereos. Sadly, they became useless if you ever lost the code. [Simon] had found a deck in great condition that was locked out, so he set about building his own controller for it.

The build relies on the cassette transport of a car stereo and a VFD display, but everything else was laced together by Simon. It’s a play-only setup, with no record, seeing as its based on an automotive unit. [Simon]’s write up explains how he reverse engineered the transport, figuring out how the motors and position sensors worked to control the playback of a cassette.

[Simon] used an Atmega microcontroller as the brains of the operation, which reads the buttons of the original deck via an ADC pin to save I/O for other tasks. The chip also drives the VFD display for user feedback, and handles auto reverse too. The latter is thanks to the transport’s inbuilt light barriers, which detect the tape’s current status. On the audio side, [Simon] whipped up his own head amplifier to process the signal from the tape head itself.

Fundamentally, it’s a basic build, but it does work. We’ve seen other DIY tape decks before, too. There’s something about this format that simply refuses to die. The fans just won’t let Compact Cassette go down without a fight. Video after the break.

youtube.com/embed/mDLw054vONI?…

Reverse-engineered schematics are de rigeur around these parts, largely because they’re often the key to very cool hardware hacks. We don’t get to see many mechanical reverse-engineering efforts, though, which is a pity because electronic hacks often literally don’t stand on their own. That’s why these reverse-engineered mechanical diagrams of the Quansheng UV-K5 portable amateur radio transceiver really caught our eye.

Part of the reason for the dearth of mechanical diagrams for devices, even one as electrically and computationally hackable as the UV-K5, is that mechanical diagrams are a lot less abstract than a schematic or even firmware. Luckily, this fact didn’t daunt [mdlougheed] from putting a stripped-down UV-K5 under a camera for a series of images to gather the raw data needed by photogrammetry package RealityCapture. The point cloud was thoughtfully scaled to match the dimensions of the radio’s reverse-engineered PC board, so the two models can work together.

The results are pretty impressive, especially for a first effort, and should make electromechanical modifications to the radio all the easier to accomplish. Hats off to [mdlougheed] for the good work, and let the mechanical hacks begin.

Nella giornata di oggi, dopo la pubblicazione delle due CVE CVE-2024-5491 e CVE-2024-5492 come riportato nel nostro precedente articolo, Citrix Netscaler pubblica ulteriori due CVE. Si tratta di ulteriori due bug di sicurezza che affliggono i prodotti NetScaler Console (precedentemente noto come NetScaler ADM), NetScaler SVM e NetScaler Agent.

Le vulnerabilità coinvolte sono:

• CVE-2024-6235: Divulgazione di informazioni sensibili (CVSSv4 Severità Critical 9.4)
• CVE-2024-6236: Negazione del servizio (CVSSv4 Severità High 7.1)

Versioni Interessate

Le versioni seguenti dei prodotti NetScaler sono soggette alle vulnerabilità:

• NetScaler Console: Versioni precedenti a 14.1-25.53
• NetScaler SVM: Versioni precedenti a 14.1-25.53, 13.1-53.17, 13.0-92.31
• NetScaler Agent: Versioni precedenti a 14.1-25.53, 13.1-53.22, 13.0-92.31

Riepilogo delle Vulnerabilità

• CVE-2024-6235: Questa vulnerabilità può consentire la divulgazione di informazioni sensibili agli attaccanti che hanno accesso all’IP della console NetScaler. È classificata con un punteggio CVSS v4.0 di 9.4, indicando un alto rischio di compromissione dei dati sensibili.
• CVE-2024-6236: Questa vulnerabilità comporta una negazione del servizio agli utenti che hanno accesso all’IP della console NetScaler, all’IP dell’agente NetScaler e all’IP SVM. Ha un punteggio CVSS v4.0 di 7.1, indicando un rischio moderato ma significativo di interruzione del servizio.

Azioni Consigliate per i Clienti da parte di Citric Netscaler

Cloud Software Group consiglia vivamente ai clienti di NetScaler Console di adottare le seguenti misure:

• Installare immediatamente le versioni aggiornate di NetScaler Console, SVM e Agent:
  
  • NetScaler Console 14.1-25.53 e successive, 13.1-53.22 e successive, 13.0-92.31 e successive
  • NetScaler SVM 14.1-25.53 e successive, 13.1-53.17 e successive, 13.0-92.31 e successive
  • NetScaler Agent 14.1-25.53 e successive, 13.1-53.22 e successive, 13.0-92.31 e successive

  
  

Questi aggiornamenti sono fondamentali per mitigare i rischi associati alle vulnerabilità CVE-2024-6235 e CVE-2024-6236, proteggendo così l’infrastruttura di rete e i dati sensibili gestiti tramite NetScaler Console.

Conclusione

La sicurezza delle infrastrutture IT è di primaria importanza. Agendo tempestivamente e applicando le patch consigliate, i clienti di NetScaler possono migliorare significativamente la sicurezza e la resilienza contro le minacce informatiche emergenti.

Restate protetti e informati, insieme possiamo rafforzare la difesa contro le vulnerabilità del ransomware e altre minacce digitali.

L'articolo Due gravi vulnerabilità sono state rilevate su Citrix NetScaler Console, Agent e SVM proviene da il blog della sicurezza informatica.