Il 10 dicembre 2024, Microsoft ha divulgato una vulnerabilità critica nel protocollo Windows Lightweight Directory Access Protocol (LDAP), identificata come CVE-2024-49113. Questa falla consente a un attaccante remoto non autenticato di causare un’interruzione del servizio (Denial of Service, DoS) sui server Windows non aggiornati, compromettendo la stabilità e la sicurezza delle reti aziendali.

Il protocollo LDAP è fondamentale per l’accesso e la gestione delle informazioni nei servizi di directory, in particolare all’interno di ambienti Active Directory di Microsoft. Una vulnerabilità in questo componente può avere ripercussioni significative sulla sicurezza delle infrastrutture IT aziendali.

Il 1º gennaio 2025, SafeBreach Labs ha pubblicato un exploit proof-of-concept (PoC) denominato “LDAPNightmare”, che dimostra come sfruttare CVE-2024-49113 per causare il crash di server Windows non aggiornati. Questo exploit, disponibile pubblicamente, evidenzia la gravità della vulnerabilità e l’urgenza di applicare le patch di sicurezza rilasciate da Microsoft.

Il PoC sviluppato da SafeBreach Labs interagisce con il protocollo Netlogon Remote Protocol (NRPC) e il client LDAP di Windows per sfruttare la vulnerabilità, causando un’interruzione del servizio sul server target. Questo tipo di attacco può essere eseguito da remoto senza necessità di autenticazione, aumentando il rischio per le organizzazioni che non hanno ancora applicato gli aggiornamenti di sicurezza.

Microsoft ha assegnato a CVE-2024-49113 un punteggio di gravità CVSS di 4.0, indicando un livello di rischio moderato. Tuttavia, la disponibilità di un exploit pubblico aumenta la probabilità che la vulnerabilità venga sfruttata in attacchi reali, rendendo fondamentale l’implementazione tempestiva delle patch di sicurezza.

Per proteggere le infrastrutture IT da potenziali attacchi che sfruttano CVE-2024-49113, è essenziale che le organizzazioni applichino immediatamente gli aggiornamenti di sicurezza forniti da Microsoft. Inoltre, è consigliabile monitorare attentamente i sistemi per rilevare eventuali attività sospette e adottare misure proattive per rafforzare la sicurezza delle reti aziendali.

L'articolo LDAPNightmare: L’Exploit è in rete per la vulnerabilità critica di Microsoft Windows proviene da il blog della sicurezza informatica.

The miniature Christmas village is a tradition in many families — a tiny idyllic world filled happy people, shops, and of course, snow. It’s common to see various miniature buildings for sale around the holidays just for this purpose, and since LEDs are small and cheap, they’ll almost always have some switch on the bottom to light up the windows.

This year, [Braden Sunwold] and his wife started their own village with an eye towards making it a family tradition. But to his surprise, the scale lamp posts they bought to dot along their snowy main street were hollow and didn’t actually light up. Seeing it was up to him to save Christmas, [Braden] got to work adding LEDs to the otherwise inert lamps.

Now in a pinch, this project could have been done with nothing more than some coin cells and a suitably sized LED. But seeing as the lamp posts were clearly designed in the Victorian style, [Braden] felt they should softly flicker to mimic a burning gas flame. Blinking would be way too harsh, and in his own words, look more like a Halloween decoration.

This could have been an excuse to drag out a microcontroller. But instead, [Braden] did as any good little Hackaday reader should do, and called on Old Saint 555 to save Christmas. After doing some research, he determined that a trio of 555s rigged as relaxation oscillators could be used to produce quasi-random triangle waves. When fed into a transistor controlling the LED, the result would be a random flickering instead of a more aggressive strobe effect. It took a little tweaking of values, but eventually he got it locked down and sent away to have custom PCBs made of the circuit.

With the flicker driver done, the rest of the project was pretty simple. Since the lamp posts were already hollow, feeding the LEDs up into them was easy enough. The electronics went into a 3D printed base, and we particularly liked the magnetic connectors [Braden] used so that the lamps could easily be taken off the base when it was time to pack the village away.

We can’t wait to see what new tricks [Braden] uses to bring the village alive for Christmas 2025. Perhaps the building lighting could do with a bit of automation?

youtube.com/embed/SH6hXkraL7c?…

hackaday.com/2025/01/02/555-ti…

The art of writing has become a cluttered one to follow, typically these days through a graphical word processor. There may be a virtual page in front of you, but it’s encumbered by much UI annoyance. To combat this a variety of distraction free software and appliances have been created over the years.

But it’s perhaps [Liam Proven]’s one we like the most — it’s a bootable 16-bit DOS environment with a selection of simple text and office packages on board. No worries about being distracted by social media when you don’t even have networking.

The zip file, in the releases section of the repository, is based upon SvarDOS, and comes with some software we well remember from back in the day. There’s MS Word 5.5 for DOS, in the public domain since it was released as a Y2K fix, Arnor Protext, and the venerable AsEasyAs spreadsheet alongside a few we’re less familiar with. He makes the point that a machine with a BIOS is required, but those of you unwilling to enable BIOS emulation on a newer machine should be able to run it in a VM or an emulator. Perhaps it’s one to take on the road with us, and bang away in DOS alongside all the high-powered executives on the train with their fancy business projections.

We recently talked about SvarDOS, and it shouldn’t come as a surprise that our article linked to a piece [Liam] wrote for The Register.

hackaday.com/2025/01/02/the-ul…

Aside from their ability to operate fairly well in extreme temperatures, lead-acid batteries don’t have many benefits compared to more modern battery technology. They’re heavy, not particularly energy dense, have limited charge cycles, and often can’t be fully discharged without damage or greatly increased wear. With that in mind, one can imagine that a laptop that uses a battery like this would be not only extremely old but also limited by this technology. Of course, in the modern day we can do a lot to bring these retro machines up to modern standards like adding in some lithium batteries to this HP laptop.

Simply swapping the batteries in this computer won’t get the job done though, as lead-acid and lithium batteries need different circuitry in order to be safe while also getting the maximum amount of energy out. [CYUL] is using a cheap UPS module from AliExpress which comes with two 18650 cells to perform this conversion, although with a high likelihood of counterfeiting in this market, the 18650s were swapped out with two that were known to be from Samsung. The USB module also needs to be modified a bit to change the voltage output to match the needs of the HP-110Plus, and of course a modernized rebuild like this wouldn’t be complete without a USB-C port to function as the new power jack.

[CYUL] notes at the end of the build log that even without every hardware upgrade made to this computer (and ignoring its limited usefulness in the modern world) it has a limited shelf life as the BIOS won’t work past 2035. Hopefully with computers like this we’ll start seeing some firmware modifications as well that’ll let them work indefinitely into the future. For modern computers we’ll hope to avoid the similar 2038 problem by switching everything over to 64 bit systems and making other software updates as well.

hackaday.com/2025/01/02/a-mode…

Especially within the world of multi-threaded programming does atomic access become a crucial topic, as multiple execution contexts may seek to access the same memory locations at the same time. Yet the exact meaning of the word ‘atomic’ is also essential here, as there is in fact not just a single meaning of the word within the world of computer science. One type of atomic access refers merely to whether a single value can be written or read atomically (e.g. reading or writing a 32-bit integer on a 32-bit system versus a 16-bit system), whereas atomic operations are a whole other kettle of atomic fish.

Until quite recently very few programming languages offered direct support for the latter, whereas the former has been generally something that either Just Worked if you know the platform you are on, or could often be checked fairly trivially using the programming language’s platform support headers. For C and C++ atomic operations didn’t become supported by the language itself until C11 and C++11 respectively, previously requiring built-in functions provided by the toolchain (e.g. GCC intrinsics).

In the case of Ada there has been a reluctance among the language designers to add support for atomic operations to the language, with the (GNU) toolchain offering the same intrinsics as a fallback. With the Ada 2022 standard there is now direct support in the System.Atomic_Operations library, however.

Defining Atomic Operations

As mentioned earlier, the basic act of reading or writing can be atomic based on the underlying architecture. For example, if you are reading a 32-bit value on a fully 32-bit system (i.e. 32-bit registers and data bus), then this should complete in a single operation. In this case the 32-bit value read cannot suddenly have 8 or 16-bits on the end that were written during said reading action. Ergo it’s guaranteed to be atomic on this particular hardware platform. For Ada you can use the Atomic pragma to enforce this type of access. E.g.:
A : Unsigned_32 with Atomic;
A := 0;

A := A + 1;
-- This generates:
804969f: a1 04 95 05 08 mov 0x8059504,%eax
80496a4: 40 inc %eax
80496a5: a3 04 95 05 08 mov %eax,0x8059504
Now imagine performing a more complex operation, such as incrementing the value (a counter) even as another thread tries to use this value in a comparison. Although the first thread’s act of reading is atomic and writing the modified value back is atomic, this set of operations is not, resulting in a data race. There’s now a chance that the second thread will read the value before it is updated by the first, possibly causing the second thread to miss the update and requiring repeated polling. What if you could guarantee that this set of atomic operations was itself atomic?

The traditional way to accomplish this is through mutual exclusion mechanisms such as the common concept of mutexes. These do however come with a fair amount of overhead when contended due to the management of the (implementation-defined) mutex structures, the management of which uses the same atomic operations which we could directly use as well. As an example there are LOCK XADD (atomic fetch and add) and LOCK CMPXCHG (atomic compare and exchange) in the x86 ISA which a mutex implementation is likely to use, but which we’d like to use for a counter and comparison function in our own code too.

Reasons To Avoid

Obviously, having two or more threads compete for the same resources is generally speaking not a great idea and could indicate a flaw in the application’s architecture, especially in how it may break modularity. Within Ada an advocated approach has been to use protected objects and barriers within entries, which provides language-level synchronization between tasks. A barrier is defined using the when keyword, followed by the condition that has to evaluate to true before execution can continue.

From a more low-level programming perspective as inspired by C code and kin, the use of directly shared resources makes more sense, and can be argued to have performance benefits. This contrasts with the philosophy behind Ada, which argues that neither safety nor ease of maintenance should ever be sacrificed in the name of performance. Even so, if one can prove that it is in fact safe and does not invite a maintenance nightmare, it could be worth supporting.

One might even argue that since people are going to use this feature anyway – with toolchain intrinsics if they have to – one may as well provide a standard library version. This is something that could be immensely helpful to newcomers as well, as evidenced by my recent attempt to port a lock-free ring buffer (LFRB) from C++ to Ada and running into the atomic operations details head-first.

Fixing A Lock-Free Ring Buffer

In my original Ada port of the LFRB I had naively taken the variables that were adorned with the std::atomic STL feature and replaced that with the with Atomic; pragma, blissfully unaware of this being actually an improvement over the ‘everything is implementation dependent and/or undefined behavior’ elements in C++ (and C). Since I insisted on making it a straight port without a major redesign, it would seem that here I need to use this new Ada 2022 library.

Since the code uses both atomic operations on Boolean and Integer types we need the following two packages:
with System.Atomic_Operations.Integer_Arithmetic;
with System.Atomic_Operations.Exchange;
These generic packages of course also need to have a specific package defined for our use:
type Atomic_Integer is new Integer with Atomic;
package IAO is new System.Atomic_Operations.Integer_Arithmetic(Atomic_Integer);

type Atomic_Boolean is new Boolean with Atomic;
package BAO is new System.Atomic_Operations.Exchange(Atomic_Boolean);
These new types are defined as being capable of atomic read and write operations, which is a prerequisite for more complex atomic operations and thus featured in the package instantiation. Using these types is required to perform atomic operations on our target variables, which are declared as follows:
dataRequestPending : aliased Atomic_Boolean;
unread : aliased Atomic_Integer;
The [url=https://en.wikibooks.org/wiki/Ada_Programming/Keywords/aliased]aliased[/url] keyword here means that the variable has to be in memory (i.e. have a memory address) and not just in a register, allowing it to be the target of an access (pointer) type.

When we want to perform an atomic operation on our variables, we use the package which we instantiated previously, e.g.:
IAO.Atomic_Subtract(unread, len);
IAO.Atomic_Add(free, len);
The first of which will subtract the value of len from unread followed by the second line which will add the same value to free. We can see that we are now getting memory barriers in the generated assembly, e.g.:
lock add DWORD PTR [rsp+4], eax #,, _10
Which is the atomic addition operation for the x86 ISA, confirming that we are now indeed performing proper atomic operations. Similarly, for booleans we can perform atomic operations such as assigning a new value and returning the previous value:
while BAO.Atomic_Exchange(dataRequestPending, false) loop
null;
end loop;

Atomic Differences

I must express my gratitude to the commentators to the previous LFRB Ada article who pointed out these differences between atomic in C++ (and C) and Ada. Along with their feedback there are also tools such as the Godbolt Compiler Explorer site where it’s quite easy to drop in some C++ and Ada code for comparison between the generated assembly, even across a range of ISAs. Since I did not consult any of these previously consider this article my mea culpa for getting things so terribly wrong earlier.

Correspondingly, before passing off the above explanation as the absolute truth, I will preface it by saying that it is my best interpretation of The Correct Way in the absence of significant amounts of example code or discussions. Currently I’m adapting the LFRB code as described as above and will update the corresponding GitHub project once I feel relatively confident that I can dodge writing a second apology article.

For corrections and feedback, feel free to sound off in the comments.

hackaday.com/2025/01/02/progra…

A questa pagina della Oxford University Press trovata una breve storia della loro "parola dell'anno" 2024 "Brain Rot", di cui avrete sicuramente letto nelle scorse settimane, e traducibile come "marciume cerebrale".
La parola è stata votata dopo una consultazione con circa 37.000 persone, e viene descritta come il deterioramento delle capacità mentali o intellettuali di una persona a causa del consumo eccessivo di materiale online di scarsa qualità o incapace di stimolare il pensiero critico (o qualsiasi tipo di pensiero).
Si lega, quindi, al fenomeno dell'eccessivo consumo di contenuti online di infima qualità.
Il primo uso "annotato" di "Brain Rot" viene individuato in un'opera del 1854 di Henry David Thoreau (nel libro "Walden") ed è riferito a uno stile di vita semplice, senza pensieri, nella natura e nei boschi.
Thoreau critica la tendenza della società di allora a dare poco valore alle idee complesse, o a idee che possono essere interpretate in tanti modi diversi, a favore di quelle semplici. E vede questo comportamento come un indice generale di declino mentale e intellettuale.
Nella nota, la OUP cita, ad esempio, i contenuti su TikTok e le Gen Z e Gen Alpha, ma anche parte del giornalismo mainstream.
Dopo che è stata annunciata la parola dell'anno, sono fioccate interviste e commenti (trovate tutto online) sugli aspetti patologici (e medici) di tale "abitudine".
Nel comunicato trovate anche un link a una clinica per la salute mentale in Nordamerica che ha pubblicato consigli online su come riconoscere e evitare il "Brain Rot".
Qui il link per un vostro approfondimento, nel caso il tema vi interessi!

@Informatica (Italy e non Italy 😁)

corp.oup.com/news/brain-rot-na…

https://t.me/ppInforma/10295

Non si tratta solo di un fuoco di paglia, ma dobbiamo chiarire alcune cose sull'intelligenza artificiale.

Quasi ogni anno riceviamo un rapporto che ci informa che qualcosa nel settore dei PC sta morendo o sta scomparendo, oppure che i giorni di qualche aspetto della tecnologia informatica sono contati.

@Intelligenza Artificiale

techradar.com/computing/laptop…

AI smartphone and laptop sales are said to be slowly dying – but is anyone surprised?

This isn't just a flash in the pan, but we need to get a few things straight about AI here

^{Zak Storey (TechRadar)}

Enrico De Nicola

Entra in vigore la Costituzione italiana, ove sono definiti i principi e la struttura della forma di governo repubblicana che gli italiani hanno preferito alla monarchia.
La carta costituzionale era stata firmata dal capo provvisorio dello Stato, Enrico De Nicola, primo presidente della Repubblica Italiana.
Fu eletto capo provvisorio dello Stato dall'Assemblea Costituente il 28 giugno 1946 e ricoprì tale carica dal 1 luglio dello stesso anno al 31 dicembre 1947. Il 1 gennaio 1948, a norma della prima disposizione transitoria e finale della Costituzione della Repubblica Italiana, esercitò le attribuzioni e assunse il titolo di Presidente della Repubblica Italiana, mantenendoli fino al successivo 12 maggio.

@Storia
@Storiaweb