Super-secure Pi-stuffed nomx email server box given a good probing Security researchers claim to have uncovered a variety of serious security holes in a heavily touted secure email server technology. Nomx, the firm behind the device, strongly disputes the claims and has challenged researchers to a hacking challenge, involving the creation of an email account on a designated remotely hosted nomx …
It runs postfix. The claims are just marketing hype from CES wrapped around a typical, mostly secure service. It is what you make it. Does it need inbound connectivity? Does it need the management interface wide open to the public Internet? When you have some security to offer people, will they apply it correctly, or at all? There are still idiots in the world who don't wear seat-belts or helmets. Let's not shed a tear if they should kill themselves through their own stupidity. I have a Pi server. It serves NFS. It does so behind two firewalls because there is no good reason to put that anywhere else. People are stupid, and will put them everywhere. I say; hack the shit out of those people. They're muggles.
"the device can't receive updates, a basic security requirement"
He who probed it, disrobed it. He who claims that an open source OS is unable to fetch package updates is a bit confused. Is he claiming that no new first party fixes/package updates are forthcoming, and made available in a timely manner (according to who?), or that the OS is now "locked down" and can't get updates through the normal methods?
This sounds like (yet another) security business trying to make a name for itself by crafting some claims on a system that most people would rightly hide the management interface behind a firewall and only access it though their own net or VPN. And another company that made some wild claims at CES about a secure email service for a $35 computer. If this isn't marketing making mountains out of molehills, I don't know what is.
Then you get into the area of, well, why does someone who has no idea how to properly setup public-facing services want to setup a public-facing service? My advice would be; no. But these muggles do it anyway. Q: Where's the security breakdown in those cases? A: With the user trying to cheap out, or over-extend their technical abilities. You know. Morons.
"He who claims that an open source OS is unable to fetch package updates is a bit confused. Is he claiming that no new first party fixes/package updates are forthcoming, and made available in a timely manner (according to who?), or that the OS is now "locked down" and can't get updates through the normal methods?"
Perhaps "can't receive updates" in the analysis should have been "doesn't receive updates". OS updates may well be available, but this is a black box device with power and Ethernet connections, no keyboard/monitor unless prised open and no management interface provided to enable/request updates. It has no SSH or Xterm interface to "use" the OS as a OS (and nor should it). So actually yes, "it can't get updates through the normal methods".
I guess NOMX will now add a button with a hooky script linked to it to call "apt get update", pipe a lot of "y" characters into it and hope for the best!
There's nothing wrong with using a Pi or similar board as part of a product. This is, in fact, basically how you build embedded networking gear and similar gizmos nowadays. Most products of this kind are basically the vendor's reference design, perhaps with some light modifications.
There isn't even necessarily much wrong with hawking a product based on standard software and a web interface on top of it (though you should definitely provide updating facilities, and not only because of security issues).
There is however much wrong with stating that said product is the most secure e-mail solution ever, some sort of innovative security revolution, and literally having "Everything else is insecure" as your motto.
Even avoiding the 'hard' issues like the lack of end-to-end encryption, secure storage, the vendor's hostile response to basic security testing, the sure-fire snake oil of a challenge with artificial conditions, etc this product has a huge issue when sold for personal/home use. Namely that it's utterly useless for that.
You can't run a mail server on a home connection and expect it to be able to deliver mail to the Internet without using a relay/smarthost. You can't even use its 'super-innovative' feature of sending directly to other NOMX boxes using SMTP on port 26, since most connections have a dynamic IP address.
The vast majority of "home" ISPs do not offer static IP addresses, much less control over PTR records.
I'd even suspect that the vast majority of homes in the US or the world aren't even covered by an ISP offering either under reasonable conditions.
Even with a static IP address, chances are it's on the Spamhaus PBL or similar. There seems to be a total absence of any notice about a need for submitting yearly PBL removal requests on the NOMX site...
Potentially even worse, if your neighbor gets infected by spamming malware, chances are the entire range is going to be considered dirty by blocklists for quite some time, and as an end-user you are going to have very little recourse in this case.
Running a mail server on a home connection is basically throwing a dice as to whether your mail will arrive, and keep arriving. Which is fine for the hobbyist (who wouldn't buy a NOMX to begin with but rather set the mail server up on their own), but not for a mass-market product.
Having every end-user be able to speak SMTP directly with the world has been tried. As soon as the spam problem started escalating, pretty much everyone involved in delivering email (except the spammers) quickly agreed this was a Very Bad Idea.
Just watched the BBC Click, and they make it sound like having a non-cloud mail server is some kind of fabulous revolutionary concept, and the idea of having a mail server under your own control and/or at home (home/office fixed IP for e.g.) is completely new and out of this world even though there's a lot of people who have been doing the server-at-home thing for years! Lots of years!
And putting a mail server into the hands of amateurs, what could possibly go wrong? Never mind the problems with selling complex stuff like it's a toaster, that's just a fail waiting to happen.
According to his write-up, they sent him an email 'challenging' him to demonstrate his claims...from one of their crappy devices, so it went to his spam folder. They didn't bother to verify receipt. Then twelve hours later they posted the claim that he hadn't been able to demonstrate.
https://twitter.com/Scott_Helme/status/857617936902754304
The built in SD card interface in Razzie is not fit for purpose for any reliable storage (as expected for email). It does the job for hobby stuff, but it is not something I would trust data 24x7x365. It will simply barf after a point. Either the controller or the electrical interface or both.
USB is even worse - any serious activity on it especially combined with network (which also internally hangs off USB) - BOOM. Add to that the fact that Model 3 (which is the only one fast enough to do full disk encryption) will crash thermally if you connect a good USB drive and use encrypted LVM. Write with it for 5-10 minutes at full throttle to a good fast USB disk and BOOM.
If it was some odd job doing storage like a DIY Time Capsule equivalent or DVR, you could have replaced it with a Banana, because that has real disk interface in the form of SATA on the SoC. The Banana is still not good enough for email though - it is a cut-down AHCI, no support for port replication so you cannot hook up two drives in a RAID config even if you wanted to. So you are down to the reliability of a single drive (still better than a razzie though).
That does not mean there are no ARM SoC which can do the job - there are aplenty (used by all those SOHO NAS devices). It is not a job for a hobby SoC though - neither for Razzie, nor for Banana. You need proper disk interface for at least 2 drives and proper NIC interface on-SoC.
So anyone who is trying to sell you a Banana based production secure email device... Just turn around... slowly... walk away... then faster... then run...
My home pi server has been running for years without problems or data corruption. I backup to a separate card frequently so should something go wrong I can just switch the card over. I also rsync to another machine. If the hardware fails, plug in another pi, put the card in, good to go with virtually no down time. You appear to be infected with enterprisitis.
The built in SD card interface in Razzie is not fit for purpose for any reliable storage (as expected for email). It does the job for hobby stuff, but it is not something I would trust data 24x7x365. It will simply barf after a point. Either the controller or the electrical interface or both.
It depends on the SD card. A few cheap cards have died on me, but the SanDisk Ultra has been reliable. However, I'm not running disk encryption, and that would drag down performance by itself anyways. I would never consider anything in a small box to be the equivalent of a real enterprise server.
If Debian can be called "secure" then so can Raspbian. How the integrator configured the system, that's another story.
The number of nomx accounts that have been compromised since inception is nil, according to Donaldson.
Well yes, the first versions of Slackware* were not hacked either when it was just brought out. It took a few weeks for someone to take a proper look at it and it emerged to be so full of holes it was a binary representation of cheese (which were then fixed). So that claim falls by the wayside already.
Next, well, the whole nonsense about the fact that a specific company, group or individual with a specific skillset was unable to break into a specific version of the product at a specific time and understanding of security is absolutely no guarantee that that remains the case - every instance of "specific" is a variable that can rip that secure status to shreds.
Security isn't a game of white hat hacking, it is a process wherein products mature over time and prove themselves not just be being safe, but also by demonstrating a process that keeps them that way. Good security people are always interested in examining new ideas, but when it comes to protection and production they tend to be arch conservative for good reasons: they manage risk.
A CEO which wants to impress me should exactly NOT utter "it has never been broken into" - you can leave the BS at home if you want to sell to me. Tell me why it's safe, and what you'll do when someone manages to break it anyway - certainly when it strikes me as simply a boxed version of a FOSS component which I have already managed to lock down nicely.
Oh, and what about storage management? Resilience? Load balancing? You know, the production stuff we have to do to make sure stuff stays online?
Just stop the marketing already.
* Yes, I'm that old. Go away.
I can think of a way to
Take the source for a mature Linux distro.
Strip every module out that's not directly needed to carry out this task. No apps included "just in case." No language processors. Include secure update facilities
Run every remaining module through source code analysis tools to identify latent bugs and insecure coding practices. Fix them and re run the tools.
Put the source code up on a site and offer generous bug bounties. Leave it for some months. Scour the internet for every possible exploit of those applications. Start work on the server side of your secure updates system.
While you're doing ind the most up to date minimal tool chain you can find and run it through the same tools.
Compile the tool change with the most minimal possible compiler. Then re-build them with full versions of the tools to get an efficient tool chain.
Now build the code and put it into the hardware.
Run all the known exploits against the code base in situ. Log any that failed then re-write to eliminate all of them. After the code has been up on the site for 3-6 months take any reported bugs and add them into the re-write process.
Re-run the code analysis tools on the source code. Drive out any further bugs found. Re-build the code, Assuming all tests are passed and all current exploits fail to penetrate ship the hardware with the current executable.
It's a long winded process and it's not cheap. It will significantly reduce the available attack surface for an attacker but it does not guarantee unconditional security for all time.
Now who thinks anyone is going to do this IRL?
Security is a process, not an event. And if you want to be a serious player IE nation state resistant security (like privacy) is pretty f**king hard to do properly.
MY bullshit detector's got a SILVER lining.
MY bullshit detector's more SHINY than your bullshit detector.
MY bullshit detector's MORE SECURE than your bullshit detector ...
NO, you can't play with MY bullshit detector. I don't want your sticky dabs on it's shiny ...
I can think of a way to
Take the source for a mature Linux distro.
Strip every module out that's not directly needed to carry out this task. No apps included "just in case." No language processors. Include secure update facilities
(etc)
From what I see, you have described the exact process this guy has been at pains to avoid..
No sale to any of my lot, I can tell you that. Besides, it's a US company so any statements of privacy protection should be taken with a boatload of salt, their legal system doesn't allow that for mere peasants.
I wouldn't be surprised as it's time consuming and damm hard work.
And in this business those spell e-x-p-e-n-s-i-v-e.
But that's the difference between real security and the appearance of security. BTW reading the article again suggests the inter-box protocol is not that secure. If that's the case anyone tapping the connection has got a window into any traffic between boxes, with a possible ability to spoof new external emails with malware on board, unless all inter-box traffic is fully encrypted.
If the inter box traffic is un-encrypted this is upgraded to an epic fail and it's a Razzie in a small box running a mail server that does not appear to be updateable.
It's really great that they seem to claim him taking it apart was somehow needed to exploit it. 'No ordinary user would do that', etc.
Like they don't even understand the difference between reverse engineering your own hardware to evaluate a product and find vulnerabilities vs. exploiting vulnerabilities once they are known.
Indeed.
If you're going to the expense of buying a separate mail server box you must already have security concerns.
Nothing can ever be totally secured but a lot can be done. It depends on the threat you're facing. What could stop 90% of all skiddies in their tracks probably wouldn't stop any state sponsored hacking crew (you chose which state you're most concerned about). Ultimately breaking into the premises if that's what it takes.
I'm not sure how good this box is. From the description definitely not state sponsored hackers. But with no update feature even the skiddies look like they've got a shot if they can find on the 'net.
I find it interesting that Nomx now say that the box that was provided for review was just a demo model.
Usually you would make that clear to a reviewer before the review and not after.
On BBC's "Click" they mentioned specifically that they ordered second box from the Nomx website and the one delivered was identical to the first one. They also mentioned clearly that there was no mention from Nomx that what they were providing to them was only a review model.
If this box did do all that Nomx claim - am I correct in thinking that in order to send 100% secure emails, everyone to whom I wanted to send email would also need to have a Nomx box?
... in the sense of, they never wrote a script that takes a vanilla Raspian install, strips out the extra packages, installs the needed ones, than configures it to work.
If there's left over test logs and stuff on the card, they plainly just widdled about with a working install until it sorta-worked, then just cloned the "golden" card to production.
How the heck they version-manage the build I don't know....
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
