Linux SambaCry

May 25, 2017 by Pedro Umbelino 25 Comments

Great news everyone, Windows is not the only operating system with remote code execution via SMB. Linux has also its own, seven-year-old version of the bug. /s

This Linux remote execution vulnerability (CVE-2017-7494) affects Samba, the Linux re-implementation of the SMB networking protocol, from versions 3.5.0 onwards (since 2010). The SambaCry moniker was almost unavoidable.

The bug, however, has nothing to do on how Eternalblue works, one of the exploits that the current version of WannaCry ransomware packs with. While Eternalblue is essentially a buffer overflow exploit, CVE-2017-7494 takes advantage of an arbitrary shared library load. To exploit it, a malicious client needs to be able to upload a shared library file to a writeable share, afterwards it’s possible for the attacker to cause the server to load and execute it. A Metasploit exploit module is already public, able to target Linux ARM, X86 and X86_64 architectures.

A patch addressing this defect has been posted to the official website and Samba 4.6.4, 4.5.10 and 4.4.14 have been issued as security releases to correct the defect. Patches against older Samba versions are also available. If you can’t apply the patch at the moment, the workaround is to add the parameter “nt pipe support = no” to the [global] section of your smb.conf and restart smbd. Note that this can disable some expected functionality for Windows clients.

Meanwhile, NAS vendors start to realise they have work on their hands. Different brands and models that use Samba for file sharing (a lot, if not all, of them provide this functionality) will have to issue firmware updates if they want to patch this flaw. If the firmware updates for these appliances take the same time they usually do, we will have this bug around for quite some time.

Hackaday Prize Entry: Heart Failure Detection Device

May 25, 2017 by Pedro Umbelino 19 Comments

Early and low-cost detection of a Heart Failure is the proposal of [Jean Pierre Le Rouzic] for his entry for the 2017 Hackaday Prize. His device is based on a low-cost Doppler device, like those fetal Doppler devices used to listen an unborn baby heart, feeding a machine learning algorithm that could differentiate between a healthy and an unhealthy heart.

The theory behind it is that a regular, healthy heart tissue has a different acoustic impedance than degenerated tissue. Based on the acoustic impedance, the device would classify the tissue as: normal, degenerated, granulated or fibrous. Each category indicates specific problems mostly in connective tissues.

There are several advantages to have a working device like the one [Rouzic] is working on. To start, it would be possible to use it at home, without the intervention of a doctor or medical staff. It seems to us that would be as easy as using a blood pressure device or a fetal Doppler. It’s also relatively cheap (estimated under 150$) and it needs no gel to work. We covered similar projects that measure different heart signals, like Open Source electrocardiography, but ECG has the downfall that it requires attaching electrodes to the body.

One interesting proposed feature is that what is learn from a single case, is sent to every devices at their next update, so the devices get ‘smarter’ as they are used. Of course, there are a lot of ways for this to go wrong, but it’s a good idea to begin with.

Music Reading For Machines

May 25, 2017 by Steven Dufresne 17 Comments

“Dammit Jim, I’m a hacker, not a musician!”, to paraphrase McCoy ~~Scotty~~ from the original Star Trek series. Well, some of us are also musicians, some, like me, are also hack-musicians, and some wouldn’t know a whole note from a treble clef. But every now and then the music you want is in the form of sheet music and you need to convert that to something your hack can play. If you’re lucky, you can find software that will read the sheet music for you and spit out a MIDI or WAV file. Or, as with my hand-cranked music player, you may have to read just enough of the music yourself to convert musical notes to frequencies for something like a 555 timer chip. We’ll dive into both cases here.

Continue reading “Music Reading For Machines” →

Coleco In Spat With ColecoVision Community

May 25, 2017 by Jenny List 82 Comments

If you were a child of the late 1970s or early 1980s, the chances are that your number one desire was to own a games console. The one to have was the Atari 2600, notwithstanding that dreadful E.T. game.

Of course, there were other consoles during that era. One of these also-ran products came from Coleco, a company that had started in the leather business but by the mid 1970s had diversified into handheld single-game consoles. Their ColecoVision console of 1982 sold well initially, but suffered badly in the video game crash of 1983. By 1985 it was gone, and though Coleco went on to have further success, by the end of the decade they too had faded away.

The Coleco story was not over though, because in 2005 the brand was relaunched by a successor company. Initially it appeared on an all-in-one retro console, and then on an abortive attempt to crowdfund a new console, the Coleco Chameleon. This campaign came to a halt after the Chameleon prototypes were shown to be not quite what they seemed by eagle-eyed onlookers. Continue reading “Coleco In Spat With ColecoVision Community” →

Ohm? Don’t Forget Kirchhoff!

May 25, 2017 by Al Williams 52 Comments

It is hard to get very far into electronics without knowing Ohm’s law. Named after [Georg Ohm] it describes current and voltage relationships in linear circuits. However, there are two laws that are even more basic that don’t get nearly the respect that Ohm’s law gets. Those are Kirchhoff’s laws.

In simple terms, Kirchhoff’s laws are really an expression of conservation of energy. Kirchhoff’s current law (KCL) says that the current going into a single point (a node) has to have exactly the same amount of current going out of it. If you are more mathematical, you can say that the sum of the current going in and the current going out will always be zero, since the current going out will have a negative sign compared to the current going in.

You know the current in a series circuit is always the same, right? For example, in a circuit with a battery, an LED, and a resistor, the LED and the resistor will have the same current in them. That’s KCL. The current going into the resistor better be the same as the current going out of it and into the LED.

This is mostly interesting when there are more than two wires going into one point. If a battery drives 3 magically-identical light bulbs, for instance, then each bulb will get one-third of the total current. The node where the battery’s wire joins with the leads to the 3 bulbs is the node. All the current coming in, has to equal all the current going out. Even if the bulbs are not identical, the totals will still be equal. So if you know any three values, you can compute the fourth.

If you want to play with it yourself, you can simulate the circuit below.

The current from the battery has to equal the current going into the battery. The two resistors at the extreme left and right have the same current through them (1.56 mA). Within rounding error of the simulator, each branch of the split has its share of the total (note the bottom leg has 3K total resistance and, thus, carries less current).

Continue reading “Ohm? Don’t Forget Kirchhoff!” →

NIST Helps You With Cryptography

May 25, 2017 by Elliot Williams 33 Comments

Getting cryptography right isn’t easy, and it’s a lot worse on constrained devices like microcontrollers. RAM is usually the bottleneck — you will smash your stack computing a SHA-2 hash on an AVR — but other resources like computing power and flash code storage space are also at a premium. Trimming down a standard algorithm to work within these constraints opens up the Pandora’s box of implementation-specific flaws.

NIST stepped up to the plate, starting a lightweight cryptography project in 2013 which has now come out with a first report, and here it is as a PDF. The project is ongoing, so don’t expect a how-to guide. Indeed, most of the report is a description of the problems with crypto on small devices. Given the state of IoT security, just defining the problem is a huge contribution.

Still, there are some concrete recommendations. Here are some spoilers. For encryption, they recommend a trimmed-down version of AES-128, which is a well-tested block cipher on the big machines. For message authentication, they’re happy with Galois/Counter Mode and AES-128.

I was most interested in hashing, and came away disappointed; the conclusion is that the SHA-2 and SHA-3 families simply require too much state (and RAM) and they make no recommendation, leaving you to pick among less-known functions: check out PHOTON or SPONGENT, and they’re still being actively researched.

If you think small-device security is easy, read through the 22-question checklist that starts on page twelve. And if you’re looking for a good starting point to read up on the state of the art, the bibliography is extensive.

Your tax dollars at work. Thanks, NIST!

And thanks [acs] for the tip!

These Engineering Ed Projects Are Our Kind Of Hacks

May 25, 2017 by Mike Szczys 23 Comments

Highly polished all-in-one gear for teaching STEM is one way to approach the problem. But for some, they can be intimidating and the up-front expenditure can be a barrier to just trying something before you’re certain you want to commit. [Miranda] is taking a different approach with the aim of making engineering education possible with junk you have around the house. The point is to play around with engineering concepts with having to worry about doing it exactly right, or with exactly the right materials. You know… hacking!