Every few years or so, a development in computing results in a sea change and a need for specialized workers to take advantage of the new technology. Whether that’s COBOL in the 60s and 70s, HTML in the 90s, or SQL in the past decade or so, there’s always something new to learn in the computing world. The introduction of graphics processing units (GPUs) for general-purpose computing is perhaps the most important recent development for computing, and if you want to develop some new Python skills to take advantage of the modern technology take a look at this introduction to CUDA which allows developers to use Nvidia GPUs for general-purpose computing.

Of course CUDA is a proprietary platform and requires one of Nvidia’s supported graphics cards to run, but assuming that barrier to entry is met it’s not too much more effort to use it for non-graphics tasks. The guide takes a closer look at the open-source library PyTorch which allows a Python developer to quickly get up-to-speed with the features of CUDA that make it so appealing to researchers and developers in artificial intelligence, machine learning, big data, and other frontiers in computer science. The guide describes how threads are created, how they travel along within the GPU and work together with other threads, how memory can be managed both on the CPU and GPU, creating CUDA kernels, and managing everything else involved largely through the lens of Python.

Getting started with something like this is almost a requirement to stay relevant in the fast-paced realm of computer science, as machine learning has taken center stage with almost everything related to computers these days. It’s worth noting that strictly speaking, an Nvidia GPU is not required for GPU programming like this; AMD has a GPU computing platform called ROCm but despite it being open-source is still behind Nvidia in adoption rates and arguably in performance as well. Some other learning tools for GPU programming we’ve seen in the past include this puzzle-based tool which illustrates some of the specific problems GPUs excel at.

Do you do PCB design for a living? Has KiCad been just a tiny bit insufficient for your lightning-fast board routing demands? We’ve just been graced with the KiCad 9 release (blog post, there’s a FOSDEM talk too), and it brings features of the rank you expect from a professional-level monthly-subscription PCB design suite.

Of course, KiCad 9 has delivered a ton of polish and features for all sorts of PCB design, so everyone will have some fun new additions to work with – but if you live and breathe PCB track routing, this release is especially for you.

One of the most flashy features is multichannel design – essentially, if you have multiple identical blocks on your PCB, say, audio amplifiers, you can now route it once and then replicate the routing in all other blocks; a stepping stone for design blocks, no doubt.

Other than that, there’s a heap of additions – assigning net rules in the schematic, dragging multiple tracks at once, selectively removing soldermask from tracks and tenting from vias, a zone fill manager, in/decrementing numbers in schematic signal names with mousewheel scroll, alternate function display toggle on symbol pins, improved layer selection for layer switches during routing, creepage and acute angle DRC, DRC marker visual improvements, editing pad and via stacks, improved third-party imports (specifically, Eagle and Altium schematics), and a heap of other similar pro-level features big and small.

Regular hackers get a load of improvements to enjoy, too. Ever wanted to add a table into your schematic? Now that’s doable out of the box. How about storing your fonts, 3D models, or datasheets directly inside your KiCad files? This, too, is now possible in KiCad. The promised Python API for the board editor is here, output job templates are here (think company-wide standardized export settings), there’s significantly more options for tweaking your 3D exports, dogbone editor for inner contour milling, big improvements to footprint positioning and moving, improvements to the command line interface (picture rendering in mainline!), and support for even more 3D export standards, including STL. Oh, add to that, export of silkscreen and soldermask into 3D models – finally!

Apart from that, there’s, of course, a ton of bugfixes and small features, ~1500 new symbols, ~750 footprints, and, documentation has been upgraded to match and beyond. KiCad 10 already has big plans, too – mostly engine and infrastructure improvements, making KiCad faster, smarter, and future-proof, becoming even more of impressive software suite and a mainstay on an average hacker’s machine.

For example, KiCad 10 will bring delay matching, Git schematic and PCB integrations, PNG plot exports, improved diffpair routers, autorouter previews, design import wizard, DRC and length calculation code refactoring, part height support, and a few dozen other things!

We love that KiCad updates yearly now. Every FOSDEM, we get an influx of cool new features into the stable KiCad tree. We’re also pretty glad about the ongoing consistent funding they get – may they get even more, in fact. We’ve been consistently seeing hackers stop paying for proprietary PCB software suites and switching to KiCad, and hopefully some of them have redirected that money into a donation towards their new favorite PCB design tool.

Join the pro club, switch to the new now-stable KiCad 9! If you really enjoy it and benefit from it, donate, or even get some KiCad merch. Want to learn more about the new features? Check out the release blog post (many cool animations and videos there!), or the running thread on KiCad forums describing the new features&fixes in length, maybe if you’re up for video format, check out the KiCad 9 release talk recording (29m48s) from this year’s FOSDEM, it’s worth a watch.

OpenSSH has a newly fixed pair of vulnerabilities, and while neither of them are lighting the Internet on fire, these are each fairly important.

The central observation made by the Qualsys Threat Research Unit (TRU) was that OpenSSH contains a code paradigm that could easily contain a logic bug. It’s similar to Apple’s infamous goto fail; SSL vulnerability. The setup is this: An integer, r, is initialized to a negative value, indicating a generic error code. Multiple functions are called, with r often, but not always, set to the return value of each function. On success, that may set r to 0 to indicate no error. And when one of those functions does fail, it often runs a goto: statement that short-circuits the rest of the checks. At the end of this string of checks would be a return r; statement, using the last value of r as the result of the whole function.

1387 int
1388 sshkey_to_base64(const struct sshkey *key, char **b64p)
1389 {
1390         int r = SSH_ERR_INTERNAL_ERROR;
....
1398         if ((r = sshkey_putb(key, b)) != 0)
1399                 goto out;
1400         if ((uu = sshbuf_dtob64_string(b, 0)) == NULL) {
1401                 r = SSH_ERR_ALLOC_FAIL;
1402                 goto out;
1403         }
....
1409         r = 0;
1410  out:
....
1413         return r;
1414 }

The potential bug? What if line 1401 was missing? That would mean setting r to the success return code of one function (1398), then using a different variable in the next check (1400), without re-initializing r to a generic error value (1401). If that second check fails at line 1400, the code execution jumps to the return statement at the end, but instead of returning an error code, the success code from the intermediary check is returned. The TRU researchers arrived at this theoretical scenario just through the code smell of this particular goto use, and used the CodeQL code analysis tool to look for any instances of this flaw in the OpenSSH codebase.

The tool found 50 results, 37 of which turned out to be false positives, and the other 13 were minor issues that were not vulnerabilities. Seems like a dead end, but while manually auditing how well their CodeQL rules did at finding the potentially problematic code, the TRU team found a very similar case, in the VerifyHostKeyDNS handling, that could present a problem. The burning question on my mind when reaching this point of the write-up was what exactly VerifyHostKeyDNS was.

SSH uses public key cryptography to prevent Man in the Middle (MitM) attacks. Without this, it would be rather trivial to intercept an outgoing SSH connection, and pretend to be the target server. This is why SSH will warn you The authenticity of host 'xyz' can't be established. upon first connecting to a new SSH server. And why it so strongly warns that IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! when a connection to a known machine doesn’t verify properly. VerifyHostKeyDNS is an alternative to trusting a server’s key on first connection, instead getting the cryptographic fingerprint in a DNS lookup.

So back to the vulnerability. TRU found one of these goto out; cases in the VerifyHostKeyDNS handling that returned the error code from a function on failure, but the code a layer up only checked for a -1 value. On one layer of code, only a 0 was considered a success, and on the other layer, only a -1 was considered a failure. Manage to find a way to return an error other than -1, and host key verification automatically succeeds. That seems very simple, but it turns out the only other practical error that can be returned is an out of memory error. This leads to the second vulnerability that was discovered.

OpenSSH has its own PING mechanism to determine whether a server is reachable, and what the latency is. When it receives a PING, it sends a PONG message back. During normal operation, that’s perfectly fine. The messages are sent and the memory used is freed. But during key exchange, those PONG packets are simply queued. There are no control mechanisms on how many messages to queue, and a malicious server can keep a client in the key exchange process indefinitely. In itself it’s a denial of service vulnerability for both the client and server side, as it can eat up ridiculous amount of memory. But when combined with the VerifyHostKeyDNS flaw explained above, it’s a way to trigger the out of memory error, and bypass server verification.

The vulnerabilities were fixed in the 9.9p2 release of OpenSSH. The client attack (the more serious of the two) is only exploitable if your client has the VerifyHostKeyDNS option set to “yes” or “ask”. Many systems default this value to “no”, and are thus unaffected.

JumbledPath

We now have a bit more insight into how Salt Typhoon recently breached multiple US telecom providers, and deployed the JumbledPath malware. Hopefully you weren’t expecting some sophisticated chain of zero-day vulnerabilities, because so far the answer seems to be simple credential stealing.

Cisco Talos has released their report on the attacks, and the interesting parts are what the attackers did after they managed to access target infrastructure. The JumbledPath malware is a Go binary, running on x86-64 Linux machines. Lateral movement was pulled off using some clever tricks, like changing the loopback address to an allowed IP, to bypass Access Control Lists (ACLs). Multiple protocols were abused for data gathering and further attacks, like SNMP, RADIUS, FTP, and SSH. There’s certainly more to this story, like where the captured credentials actually came from, and whose conversations were actually targeted, but so far those answers are not available.

Ivanti Warp-Speed Audit

The preferred method of rediscovering vulnerabilities is patch diffing. Vendors will often announce vulnerabilities, and even release updates to correct them, and never really dive into the details of what went wrong with the old code. Patch diffing is looking at the difference between the vulnerable release and the fixed one, figuring out what changed, and trying to track that back to the root cause. Researchers at Horizon3.ai knew there were vulnerabilities in Ivanti’s Endpoint manager, but didn’t have patches to reverse engineer. Seems like a bummer, but was actually serendipity, as the high-speed code audit looking for the known vulnerability actually resulted in four new ones being found!

They are all the same problem, spread across four API endpoints, and all reachable by an unauthenticated user. The code is designed to look at files on the local filesystem, and generate hashes for the files that are found. The problem is that the attacker can supply a file name that actually resolves to an external Universal Naming Convention (UNC) path. The appliance will happily reach out and attempt to authenticate with a remote server, and this exposes the system to credential relay attacks.

RANsacked

The Florida Institute for Cybersecurity Research have published a post and paper (PDF) about RANsacked, their research into various LTE and 5G systems. This is a challenging area to research, as most of us don’t have any spare LTE routing hardware laying around to research on. The obvious solution was to build their own, using open source software like Open5GS, OpenAirInterface, etc. The approach was to harness a fuzzer to find interesting vulnerabilities in these open implementations, and then apply that approach to closed solutions. Serious vulnerabilities were found in every target the fuzzing system was run against.

Their findings break down into three primary categories of vulnerabilities. The first is untrusted Non-Access Stratum (NAS) control messages getting handled by the “core”, the authentication, routing, and processing part of the cellular system. These messages aren’t properly sanitized before processing, leading to the expected crashes and exploits we see in every other insufficiently hardened system that processes untrusted data. The second category is the uncertainty in the protocol specifications and mismatch between what those specifications seem to indicate and the reality of cellular traffic. And finally, deserialization of ASN.1 data itself is subject to deserialization attacks. This group of research found a staggering 119 vulnerabilities in total.

Bits and Bytes

[RyotaK] at GMO Flatt Security found an interesting vulnerability in Chatwork, a popular messaging application in Japan. The desktop version of this tool is just an electron app, and it makes use of webviewTag, an obsolete Electron feature. This quirk can be combined with a dangerous method in the preload context, allowing for arbitrary remote code execution when a user clicks a malicious link in the application.

Once upon a time, Microsoft published Virtual Machines for developers to use for testing websites inside Edge and IE. Those VM images had the puppet admin engine installed, but no configuration set. And that’s not great, because in this state puppet will look for machine using the puppet hostname on the local network, and attempt to download a configuration from there. And because puppet is explicitly designed to administer machines, this automatically results in arbitrary code execution. The VMs are no longer offered, so we’re past the expiration date on this particular trick, but what an interesting quirk of these once-official images.

[Anurag] has an analysis of the Arechclient2 Remote Access Trojan (RAT). It’s a bit of .NET malware, aggressively obfuscated, that collects and exfiltrates data and credentials. There’s a browser element, in the form of a Chrome extension that reports itself as Google Docs. This is more data collection, looking for passwords and other form fills.

Signal users are getting hacked by good old fashioned social engineering. The trick is to generate a QR code from Signal that will permit the account scanning the code to log in on another device. It’s advice some of us have learned the hard way, but QR codes are just physical manifestations of URLs, and we really shouldn’t trust them lightly. Don’t click that link, and don’t scan that QR code.

The release notes for the 2.1.1 Raspberry Pi Pico SDK have a late holiday present: The RP2040 chip is now certified to run at 200 MHz if you use at least 1.15V as the supply voltage.

Previously, the certified speed was 125 MHz, although it was well-known you could overclock the device. By default, the 125 MHz figure is still what you’ll get, though. If you want a higher frequency, you need to set SYS_CLK_MHZ to 200 before doing a build.

They hint that more speed increases may happen in the future. If you want do go as fast as they’ll allow, you can set PICO_USE_FASTEST_SUPPORTED_CLOCK=1 instead. This will always pick the highest frequency which is currently 200 MHz.

There are other updates, too, of course. We noted several bug fixes and a new version of TinyUSB. There are also some new examples, including a few that they forgot to mention in version 2.1.0. We were particularly interested in the mqtt examples, a PIO/DMA UART example, and the multi CDC USB example, something we’ve struggled to work around before on other projects.

So what will you do with a faster Pico? We doubt we are going to see a practical 1 GHz overclock. The emphasis is on the word practical. But we have seen 312 MHz.

There are a whole bunch of different ways to create 3D scans of objects these days. Researchers at the [UW Graphics Lab] have demonstrated how to use a small, cheap time-of-flight sensor to generate scans effectively.

The key is in how time-of-flight sensors work. They shoot out a distinct pulse of light, and then determine how long that pulse takes to bounce back. This allows them to perform a simple ranging calculation to determine how far they are from a surface or object.

However, in truth, these sensors aren’t measuring distance to a single point. They’re measuring the intensity of the received return pulse over time, called the “transient histogram”, and then processing it. If you use the full mathematical information in the histogram, rather than just the range figures, it’s possible to recreate 3D geometry as seen by the sensor, through the use of some neat mathematics and a neural network. It’s all explained in great detail in the research paper.

The technique isn’t perfect; there are some inconsistencies with what it captures and the true geometry of the objects its looking at. Still, the technique is young, and more work could refine its outputs further.

If you don’t mind getting messy, there are other neat scanning techniques out there—like using a camera and some milk.

If you’ve been waiting for news from our upcoming Hackaday Europe event in March, wait no longer. We’re excited to announce the first slice of our wonderful speakers lineup! Get your tickets now,

Hackaday Europe is going down again in Berlin this year on March 15th and 16th at MotionLab. It’s Hackaday, but in real life, and it’s too much fun.  The badge is off-the-scale cool, powered by the incredible creativity of our community who entered the Supercon SAO contest last fall, and we’re absolutely stoked to be tossing the four winning entries into your schwag bag in Europe.

If you already know you’ll be attending and would like to give a seven-minute Lightning Talk on Sunday, we’re also opening up the call for talks there. Tell us now what you’d like to talk about so we can all hear it on Sunday morning.

We’re looking forward to the talks and to seeing you all there! We’re getting the last few speakers ironed out, have a keynote talk to announce, and, of course, will open up workshop signups. So stay tuned!

Rev up your browsers, package managers, or whatever other tool you use to avail yourself of new software releases, because the KiCAD team have announced that barring any major bugs being found in the next few hours, tomorrow should see the release of version 9 of the open source EDA suite. Who knows, depending on where you are in the world that could have already happened when you read this.

Skimming through the long list of enhancements brought into this version there’s one thing that strikes us; how this is now a list of upgrades and tweaks to a stable piece of software rather than essential features bringing a rough and ready package towards usability. There was a time when using KiCAD was a frustrating experience of many quirks and interface annoyances, but successive versions have improved it beyond measure. We would pass comment that we wished all open source software was as polished, but the fact is that much of the commercial software in this arena is not as good as this.

So head on over and kick the tires on this new KiCAD release, assuming that it passes those final checks. We look forward to the community’s verdict on it.