Have you ever read about something and thought, “Gee whiz! Why did I never think about that?” That was my reaction to reading about a feature commonly associated with Klipper called adaptive bed leveling or adaptive mesh leveling. Too bad I don’t typically use Klipper, but it all worked out, and I’ll show you how it might work for you.

What Is It?

Time to tram your bed!
Once a luxury, most 3D printers now come with some kind of bed level sensor. The idea is that the printer can probe the bed to determine the shape of the build plate and then adjust the build plate accordingly. So if a particular spot on the bed is 0.5 mm too high, the nozzle can rise 0.5 mm when it is in that area. There are several techniques Marlin firmware uses, including what I usually use: UBL. Some people scan the bed once and hope it won’t change much. Others will do a time-consuming scan before each print.

However, adaptive bed leveling is a bit different. The idea is that the printer only probes the area where the part is going to print. If your print bed is 235 mm x 235 mm but your part is 50 mm square, you could just probe the points under the 50 mm square.

This does several things. For a given number of points, there is less motion, so it should be faster. Also, for the same number of points, you will have a much denser mesh and, thus, a better idea of what the bed is at any given point. You could even reduce the number of points based on the size of the part you are printing.

When you think about it, it is a dead simple idea. What’s not to love? For most print jobs, you’ll have less work for the printer, faster prints, and a denser mesh. But how do you do it?

How Do You Do It?

Can you make this work with your printer? Maybe. The trick is you need a way to tell your printer firmware to restrict the mesh area. You also need a way to have the slicer output a bounding box for the part, but that’s usually not hard. If you had to, you could even post process your Gcode and figure that out, but you probably won’t have to.

I
Giving your sensor less distance to travel is a good thing
f you use linear or bilinear leveling, you are in business. That’s because the G29 command for bilinear accepts an L, R, F, and B parameter that lets you set the left, right, front, and back measurements of the probing grid. You can also set the number of probe points with H. Actually, H sets one side of the square, so if H=5, you will probe 25 points in the area.

However, I use UBL, and on one of my printers, I think I’m out of luck without changing something in the firmware. While there is a mesh inset setting, it is set when you build the firmware, so it won’t be practical to change it on the fly.

However, two of my printers are Ender 3 v2 Neo machines. By themselves, they use some odd variant of normal leveling, but I long ago flashed them with the excellent “professional” firmware by [mriscoc]. This is Marlin configured for these machines and — at least the version I use — has UBL set. But, there’s a catch.

The firmware has some custom Gcodes that start with C. C29 sets the mesh size and location very much like other versions. For some reason, it also sets the temperature. Here’s the documentation:

C29 Ln Rn Fn Bn Tn Nn Xn Ym : set probing mesh inset (Left, Right, Front, Back) in mm. T is the probing temperature (T0 doesn’t change the current bed temperature) and N is the density or amount of grid points NxN, it is posible to set a NxM density by using X and Y. In UBL use G29 S# to save to a mesh slot number #.

Try It!

Just as an experiment, I sent the following to the printer via a terminal:
C29 L100 R150 F100 B150 T0 N5
Nothing happened. But when I performed a G29 P1 to probe the bed, it obeyed the new restriction. All that was left was to make the slicer output the correct startup code. Of course, if you are using bilinear levelling, you’ll use G29 instead and have to change a few of the arguments.

Engage Start Up Sequence

Most slicers allow you to put placeholder variables in your Gcode scripts. You may have to look it up for your slicer. There are also plugins that can do the work, but you’d need to change their G29 to C29 (in my case). I mostly use SuperSlicer, which is forked from PrusaSlicer, which is forked from Slic3r.

Here’s part of my startup code:
G28 ; home all
C29 L{first_layer_print_min[0]} R{min(190,first_layer_print_max[0])} F{first_layer_print_min[1]} B{min(180,first_layer_print_max[1])} T0 N5
G29 P1 ; probe
G29 A ; activate (may not be needed?)
G29 F2 ; Fade height 2mm (or whatever you want)
That’s it. If you have a line that purges your nozzle, you might want to correct it using similar logic or just add a few skirt loops in the slicer and forget about it. Note that I probe 25 points, which might be a bit much for a small part. It would be nice to write a script to detect how big a part is and adjust things. Note that Prusa has enough power to do this totally in the start code, but it would be different in Slic3r or Cura. If you look around, there are a few different examples of doing this for both slicers and various firmware that you will — no doubt — have to adapt to your circumstances.

I need to crack into the firmware for my other printer to see if a similar C command is feasible to add. But that’s for another day, especially since the C29 command is provided as object code only, so I’ll have to start from scratch. Luckily, I’m used to building (and rebuilding) Marlin for all the machines, especially that one, since it is a custom blend of many parts. I may switch out to bilinear leveling. Or, I could break down and go to Klipper, I suppose.

We want to try fast scanning next. Of course, things are simple if you tram your flat bed once and forget it. That is until something changes.

Recentemente è emerso un allarme nel mondo della sicurezza informatica: un attore malintenzionato ha annunciato la vendita di una vulnerabilità 0-Day di tipo Use After Free (UAF) nel kernel Linux su un noto forum del dark web. Questa vulnerabilità, se sfruttata, permetterebbe l’esecuzione di codice con privilegi elevati, rappresentando una seria minaccia per i sistemi affetti.

Dettagli della Vulnerabilità

Il post dell’attore malintenzionato specifica che la vulnerabilità riguarda la versione 6.6.15-amd64 del kernel Linux. Le vulnerabilità 0-Day UAF si verificano quando la memoria precedentemente liberata viene successivamente utilizzata, permettendo ad un attaccante di eseguire codice arbitrario con privilegi elevati (Local Privilege Escalation), bypassando le normali misure di sicurezza del sistema operativo​.

Modalità di Vendita

Nell’annuncio affermano: “selling 0day Use-after free in the Linux Kernel, you can use it to do a Privileged Code Execution ( LPE (Local Privilege Escalation), or execute code with root privileges ), ( Data Leakage)..etc”

L’annuncio include anche il prezzo per l’acquisto della vulnerabilità, fissato a 150.000 USD. I pagamenti accettati sono esclusivamente in criptovalute, specificamente Monero (XMR) o Bitcoin (BTC). L’uso di criptovalute è probabilmente scelto per garantire l’anonimato delle transazioni.

Immagine del post rinvenuto nel darkweb

Intermediario

Nel post, viene menzionato un altro attore malintenzionato, noto con l’alias IntelBroker, che agisce come intermediario e dunque ne facilita la transazione. L’uso di un intermediario può servire a garantire una certa trasparenza e fiducia tra le parti coinvolte, sebbene operino comunque nell’anonimato.

La vendita di vulnerabilità 0-Day rappresenta una minaccia significativa per la sicurezza informatica globale. Gli amministratori di sistema e i professionisti della sicurezza devono essere costantemente vigili e pronti ad applicare patch di sicurezza non appena queste diventano disponibili. La comunità di sicurezza deve inoltre collaborare per identificare e mitigare tali minacce il più rapidamente possibile.

Conclusioni

La scoperta di questa vendita di una vulnerabilità 0-Day nel kernel Linux sottolinea ancora una volta l’importanza della sicurezza informatica e la necessità di rimanere vigili contro le minacce emergenti. La comunità tecnologica deve continuare a investire in misure di sicurezza preventive e reattive per proteggere i sistemi e i dati sensibili da attacchi sempre più sofisticati.

L'articolo 150.000 dollari. Il costo di uno 0-Day UAF nel Kernel Linux sul Dark Web proviene da il blog della sicurezza informatica.

Another alarming discovery in the cyber-security landscape shakes the internet. A threat actor put on sale (on BreachForum) a dangerous 0-day vulnerability affecting the Google Chrome browser. This flaw, named “Sandbox RCE”, allows for arbitrary code execution with high privileges, exposing vulnerable systems to an elavated risk.

VULNERABILITY DETAILS

The advertisement specifies that the vulnerability has been tested on two distincts Chrome versions (126.0.6478.128 and 126.0.6478.127) and the targets Windows OS systems (version 21H1 e 21H2). A RCE is a critical vulnerability that permits a bad actor to execute malicious code on a target device remotely, without the victim’s knowledge. The threat is amplified because it bypass the browser’s sandbox, an enviroment designed to isolate browser’s processes from accessing the OS.

PAYMENT METHODS

In the sale announcement the seller states “Selling Chome Sandbox Escape RCE in chrome”, including the price fixed at 1.000.000 USD. The only payment methods allowed are Monero (XMR) or Bitcoin (BTC), cryptocurrency use grant anonymous payments. The elevated cost suggests thatan highly reliable and powerful exploit.

THE MIDDLE MAN

A well-known threat actor called IntelBroker would act as middleman making easy the payment and exploit delivery. Moreover a middleman should provide trust and transparency incentivizing the purchase. This specific couple of buyre and middle-man are the same that provided another advertisment for a Linux Kernel 0-day a few days ago.

SECURITY MEASURES

0-day vulnerabilities define the biggest threat in the digital space, this flaw are unknown to the product supplier and the patch cannot be developed until a proof of the vulnerability gets uncovered. In the context of the Chrome Browser’s Sandbox the potential bypass of the safeguars and the possibility of execute code at OS level expose systems to an high risk. Every user and company should implement available security measures to protect their system. Sharing and collaboration of information inside the infosec community are essential to face dangerous threat like 0-days in an efficient way.

CONCLUSION

Chrome is the most used web browser in the world, with a market share >60%. This means the potential victims range is really wide. Regular updates, security softwareand common sense are required to avoid to be caught by this exploit. Regardless all the mitigation measures active in systems we must remember the zero risk doesn’t exist.

L'articolo 0-day SandBox RCE in Google Chrome on Sale! proviene da il blog della sicurezza informatica.

Negli ultimi mesi, la comunità della sicurezza informatica ha scoperto un nuovo worm noto come P2PInfect che ha iniziato a prendere di mira i server Redis vulnerabili. Questo malware non solo si diffonde rapidamente attraverso una rete peer-to-peer, ma sfrutta anche una vulnerabilità critica per stabilire un controllo persistente sui sistemi infetti. Il worm rappresenta una minaccia significativa sia per i server Linux che Windows, e il suo comportamento sofisticato richiede attenzione immediata da parte degli amministratori di sistema per prevenire possibili compromissioni. Ecco una panoramica dettagliata di come opera P2PInfect e le misure necessarie per mitigare questa minaccia.

Caratteristiche del Worm P2PInfect

P2PInfect è scritto in Rust, un linguaggio che facilita la sua operatività su piattaforme sia Windows che Linux. Il malware sfrutta una vulnerabilità di sandbox escape di Lua (CVE-2022-0543), che consente l’esecuzione di codice remoto sui server Redis vulnerabili. La sua capacità di replicarsi in un ambiente distribuito gli permette di creare una rete peer-to-peer (P2P), eliminando la necessità di un server di controllo centralizzato e rendendo più complesso il tracciamento e l’interruzione delle sue attività​ (SecurityWeek)​​ (SOCRadar® Cyber Intelligence Inc.)​.

Dettagli sulla CVE-2022-0543

CVE-2022-0543 è una vulnerabilità critica che affligge Redis, un database in-memory molto popolare. Questa vulnerabilità è una “sandbox escape” che consente agli attaccanti di eseguire codice arbitrario sul server vulnerabile.

Descrizione della Vulnerabilità

La CVE-2022-0543 è causata da un difetto nella gestione del codice Lua all’interno di Redis. Lua è un linguaggio di scripting leggero utilizzato in Redis per estendere le funzionalità del database. La vulnerabilità si verifica quando un attaccante può sfruttare la sandbox Lua per eseguire comandi non autorizzati sul sistema host. Questo exploit permette l’esecuzione di comandi con i privilegi dell’utente Redis, che spesso è configurato con diritti elevati sul server.

Meccanismo di Attacco

1. Inserimento di Codice Maligno: L’attaccante inserisce un payload Lua dannoso nel database Redis.
2. Esecuzione del Payload: Il payload viene eseguito all’interno del contesto della sandbox Lua, ma a causa della vulnerabilità, riesce a superare le restrizioni della sandbox.
3. Esecuzione di Codice Arbitrario: Una volta evasa la sandbox, l’attaccante può eseguire comandi arbitrari sul server, compreso il download e l’esecuzione di ulteriori malware o la manipolazione dei dati memorizzati.

Impatti

Questa vulnerabilità consente agli attaccanti di prendere il controllo completo del server Redis compromesso, eseguendo qualsiasi comando con i privilegi dell’utente Redis. Questo potrebbe portare a:

• Furto di dati: Accesso non autorizzato e esfiltrazione dei dati memorizzati.
• Compromissione del sistema: Installazione di backdoor, rootkit o altri tipi di malware.
• Interruzione del servizio: Manipolazione o cancellazione dei dati, causando disservizi.

Modalità di Attacco e Persistenza

Una volta compromesso un server Redis, P2PInfect carica un file oggetto condiviso dannoso per ottenere l’accesso alla shell inversa, mantenendo la funzionalità normale del server per evitare sospetti. Il worm utilizza varie tecniche per mantenere il controllo, inclusi aggiornamenti dinamici della configurazione in memoria e meccanismi di persistenza cron per riattivare il payload principale ogni 30 minuti. Inoltre, il malware può sovrascrivere le chiavi SSH autorizzate per prevenire l’accesso legittimo e, se ottiene l’accesso root, modifica le password degli utenti per bloccarli fuori dal sistema​ (SOCRadar® Cyber Intelligence Inc.)​​ (Heimdal Security)​.

Cosa sono i Server Redis

Redis (REmote DIctionary Server) è un database in-memory open source utilizzato come database, cache e broker di messaggi. È noto per le sue alte prestazioni e la sua versatilità, essendo capace di gestire una varietà di strutture dati come stringhe, hash, liste, set e sorted set.

Caratteristiche Principali di Redis

1. In-Memory Storage: Redis memorizza i dati interamente in memoria, il che permette una velocità di accesso estremamente rapida.
2. Strutture Dati Avanzate: Supporta vari tipi di dati avanzati come liste, set, hash, bitmap, e HyperLogLog, tra gli altri.
3. Persistenza: Redis può essere configurato per salvare periodicamente i dati su disco, garantendo la persistenza dei dati anche dopo riavvii del server.
4. Replica e Alta Disponibilità: Supporta la replica dei dati su più nodi, creando configurazioni master-slave per alta disponibilità e failover automatico.
5. Supporto per Script Lua: Redis permette l’esecuzione di script Lua per estendere le sue funzionalità e ottimizzare operazioni complesse direttamente all’interno del database.

Utilizzi Comuni di Redis

• Cache: Utilizzato per memorizzare temporaneamente dati che devono essere rapidamente accessibili.
• Database NoSQL: Utilizzato come database NoSQL per applicazioni che richiedono alte prestazioni.
• Broker di Messaggi: Utilizzato per implementare code di messaggi tra diversi componenti di un’applicazione.
• Session Store: Utilizzato per memorizzare sessioni utente in applicazioni web ad alta scalabilità.

Redis è ampiamente adottato in molti settori grazie alle sue prestazioni elevate e alla sua capacità di scalare orizzontalmente, supportando un gran numero di connessioni simultanee e operazioni al secondo.

Diffusione e Attività Recenti

A partire da agosto 2023, l’attività del botnet P2PInfect ha subito un notevole incremento, con tentativi di accesso iniziale che sono aumentati di 600 volte in settembre. Questo aumento dell’attività è stato accompagnato dall’emergere di nuove varianti del malware, suggerendo un continuo sviluppo da parte degli autori del worm. Le regioni più colpite includono Cina, Stati Uniti, Germania, Singapore, Hong Kong, Regno Unito e Giappone​ (SecurityWeek)​​ (SOCRadar® Cyber Intelligence Inc.)​.

Finalità e Potenziali Rischi

Gli obiettivi finali dei gestori di P2PInfect non sono ancora chiari. Sebbene il worm abbia tentato di scaricare payload per il cryptomining, non è stata rilevata attività di mining effettiva sui dispositivi compromessi. Questo potrebbe indicare che gli operatori stanno ancora testando le fasi finali dell’attacco o che stanno cercando di vendere l’accesso alla rete infetta ad altri cybercriminali​ (SOCRadar® Cyber Intelligence Inc.)​​ (Heimdal Security)​.

Misure di Sicurezza

Per proteggersi da P2PInfect, è essenziale che gli amministratori di server Redis aggiornino le loro istanze con le ultime patch di sicurezza e configurino adeguatamente i firewall per limitare l’accesso ai porti critici. Monitorare costantemente le attività di rete e implementare misure di rilevamento delle intrusioni può aiutare a identificare e mitigare tempestivamente le minacce​ (SecurityWeek)​​ (Heimdal Security)​.

Conclusione

La vulnerabilità CVE-2022-0543 rappresenta una seria minaccia per i server Redis non configurati correttamente o non aggiornati. Sfruttando questa falla, gli attaccanti possono eseguire codice arbitrario e prendere il controllo dei server vulnerabili. Redis, d’altro canto, rimane uno strumento potente e versatile per la gestione dei dati in memoria, essenziale per molte applicazioni moderne. È cruciale che gli amministratori mantengano i loro sistemi aggiornati e seguano le migliori pratiche di sicurezza per mitigare i rischi associati a queste vulnerabilità.

L'articolo P2PInfect: La Nuova Minaccia per i Server Redis proviene da il blog della sicurezza informatica.

Bug reporting doesn’t usually have a lot of visuals. Not so with the visionOS bug [Ryan Pickren] found, which fills a user’s area with screeching bats after visiting a malicious website. Even better, closing the browser doesn’t get rid of them! Better still? Doesn’t need to be bats, it could be spiders. Fun!

The bug has been fixed, but here’s how it worked: the Safari browser build for visionOS allowed a malicious website to fill the user’s 3D space with animated objects without interaction or permission. The code to trigger this is remarkably succinct, and is actually a new twist on an old feature: Apple AR Quick Look, an HTML-based feature for rendering 3D augmented reality content in Safari.
How about spiders, instead?
Leveraging this old feature is what lets an untrusted website launch an arbitrary number of animated 3D objects — complete with sound — into a user’s virtual space without any interaction from the user whatsoever. The icing on the cake is that Quick Look is a separate process, so closing Safari doesn’t get rid of the pests.

Providing immersive 3D via a web browser is a valuable way to deliver interactive content on both desktops and VR headsets; a good example is the fantastic virtual BBC Micro which uses WebXR. But on the Apple Vision Pro the user is always involved and there are privacy boundaries that corral such content. Things being launched into a user’s space in an interaction-free way is certainly not intended behavior.

The final interesting bit about this bug (or loophole) was that in a way, it defied easy classification and highlights a new sort of issue. While it seems obvious from a user experience and interface perspective that a random website spawning screeching crawlies into one’s personal space is not ideal, is this a denial-of-service issue? A privilege escalation that technically isn’t? It’s certainly unexpected behavior, but that doesn’t really capture the potential psychological impact such bugs can have. Perhaps the invasion of personal space and user boundaries will become a quantifiable aspect of bugs in these new platforms. What fun.