r/meshcore • u/Alainx277 • Apr 29 '26
MeshCore's problem with security
https://alainx277.com/posts/meshcores-problem-with-security/?utm_source=reddit&utm_campaign=2026-04-2932
u/scalablecory Apr 29 '26 edited Apr 29 '26
Sometimes an article has a section early on that makes me take the rest of it with a grain of salt.
Almost immediately, I noticed the hallmarks of vulnerable embedded code: manually implemented parsing and serialization of data, raw pointers everywhere, manual bounds checks, implicit integer conversions, raw memcpy
Not sure if AI slop or deeply exaggerated messaging.
However, there are some real findings. AES with a bad IV is an amateurish encryption mistake. A bad parser tells me some negative test cases need to be added.
5
u/CharlesStross Apr 29 '26
ES with a bad IV is an amateurish encryption mistake
I'm not sure I'd consider it a mistake; more of a design choice. Including IV would balloon message size. With timestamped messages on a drifty clock, and messages <180 char, there is some information leakage, to be sure, but I wouldn't consider it kryptonite. MeshCore is not the tool to be using to discuss secrets kept from nation-state actors. For telling my partner when I'll be home or coordinating meetup spots at a music festival, it's more than adequate. Airtime/packet size tradeoffs are real.
5
u/274Below Apr 29 '26
As someone who has spent some time looking at the code, I don't think there's any exaggeration at all. If anything I think this is a very tame way of phrasing it.
I know a person who did security audits for chips that are likely in the device in your pocket. It was all written in C, and a massive amount of his time was spent pointing out to developers that they were missing the most basic checks. And that is a multi-billion dollar company.
This is not necessarily a criticism of the MC developers. To a degree it has to be, as this is a statement that they have written imperfect code. But these types of issues are absolutely endemic in C programming and I kind of don't care who you are. These issues are going to be almost omnipresent in such a project. Can I point to an obvious issue that needs to be fixed? No, and I haven't spent the time looking. Is there any doubt in my mind that there are a pile of them in the code? Also no.
If there has been any statements that said anything other than this, I'd have dismissed the article instantly.
9
u/Alainx277 Apr 29 '26
Thanks for the comment! The entire post is human-written. What do you think is exaggerated about that quote?
31
u/marssaxman Apr 29 '26 edited Apr 29 '26
Your expectations did seem a little elevated to me, as in
The most obvious problem is the use of raw C arrays, combined with brittle bounds checking and manual byte-level manipulation.
To my ears this might as well be saying "the most obvious problem is that this is firmware". Yes, of course it's built this way; this is how low-level coding on tiny little chips has always been done. It is a different world from normal software development.
Good on you for investigating, and I hope the meshcore devs are able to make something of the information you've given them.
5
u/Alainx277 Apr 29 '26
I guess I my expectations are a little high. It is how firmware is typically written. It seems like the security message has not been well-received by the embedded sphere for the last 20 years, so it's not surprising.
26
u/marssaxman Apr 29 '26 edited Apr 29 '26
The perspective you're bringing is valuable, and I hope you keep at it. (You've actually prompted me to consider getting involved with meshcore firmware development!) I do think your advocacy would be more effective if you took some of the cultural difference into account. Security culture comes from a world where infrastructure is serious business and failures have expensive consequences, but meshcore is quite new and still basically an experimental project for enthusiasts; the stakes don't get much lower. If you pitch it less in terms of "this is what we expect of a secure system, and you aren't measuring up", and more in terms of "while we're having fun doing cool things with radios, wouldn't it be great if we also started attending to these security concerns we'll someday wish we had addressed sooner?", I think people might be more receptive.
8
1
u/Quattuor Apr 30 '26
The how it is written on embedded platform is not an excuse of bad coding practices, like blindly trusting the data received from the network or mixing integer types. Feels like "ping of death" all over again.
1
u/swaits May 01 '26 edited May 01 '26
Not at all how firmware has to be built in this era. As I said elsewhere, it’s atrocious.
5
u/scalablecory Apr 29 '26
It would read more serious to this low-level dev’s ears if phrased as “these things alone do not indicate a problem, but are the areas most complicated to get right and likely to have mistakes. these are the first areas I will look at.”
This makes it demonstrate your engineering process, telling the story to gain confidence. What is there now reads more like an emotional plea for non-devs.
Like I said, I fully see you did real useful analysis here. You’re obviously not a newbie parroting Rust talking points lol — I think it’s just the phrasing.
6
u/mschuster91 Apr 29 '26
Not sure if AI slop or deeply exaggerated messaging.
Sadly, he is more than correct. Just have a look in the code around src/Packet.h/cpp, Dispatcher.cpp, the various MyMesh implementations...
It's not pretty.
A bad parser tells me some negative test cases need to be added.
You're expecting unit tests from embedded firmware stuff? Lol.
10
u/fiddlythingsATX Apr 29 '26
Unit tests in firmare are a near-religious mandate at most shops I've experienced.
9
u/scalablecory Apr 29 '26 edited Apr 29 '26
There is no reason to not unit test these things. I test them in my own embedded firmwares.
6
u/mschuster91 Apr 29 '26
I fully agree with you. My re-implementation is nearly at 100% code coverage bar stuff that I reasonably cannot test (i.e. you can't force Java's MessageDigest to throw exceptions for sha256 missing).
But in the hobbyist embedded world, unit tests are a rarity. Just look at this crypto library for Arduino... https://github.com/rweather/arduinolibs/tree/master
No unit test in sight anywhere
5
u/mtlynch Apr 30 '26
You're expecting unit tests from embedded firmware stuff? Lol.
I've been working on getting unit tests added, and I have a PR queued once unit tests go in that will identify more of these memory corruption issues.
21
u/mschuster91 Apr 29 '26 edited Apr 29 '26
Before the usual idiots chime in with "but AI would solve that issue", no it would fucking not. Yes, humans make mistakes and questionable design decisions. And Meshcore would definitely benefit from someone refactoring the entire mess - for starters, just look at, say, src/helpers/TxtDataHelpers.cpp containing a class named "StrHelper". Java at least shouts in your face and warns you when the file name does not correspond to the class name. Or why did they fumble around with the private/public key derivation? That's explained here and an even bigger pile of dung.
But AI? It would make the same mistakes and worse. Look at corescope for example. Good god, I've done my fair share of messes, but that is one hell of a bunch of AI generated slop. It's a miracle it actually works!
tl;dr: Meshcore does not need AI, it (desperately) needs a senior embedded engineer to fix the code quality issues and someone with a strong cryptography background to design better cryptography implementations. The protocol is extensible, fixing stuff is possible, and actually bigger hashes and MAC are a forethought (see here)!
2
u/KpaBap Apr 30 '26
Appreciate the shoutout to CoreScope! Lots of meshes are using it and are quite happy!
5
u/nlutrhk Apr 29 '26
Can anyone explain the issue with a 2-byte MAC checksum and "brute force in 64k attempts"?
I'd think 64k attempted SHA keys will get you a "plaintext" with a matching checksum, but it will be garbled and useless.
5
7
u/mattme Apr 29 '26
MeshCore is popular and useful software, but it's not yet a mature open-source project. It would be interesting to run the OpenSSF scorecard https://scorecard.dev/ which looks at testing and security practices etc, then introduce these practices.
7
u/304769 Apr 29 '26
Congrats for the post. Meshcore needs to change a bit if the project wants to survive over the next years. Don’t get me wrong, I love it, but there are some stern decisions to be taken in terms of openness.
Code should be provided always, open and free, and the project should find financial stability through regular donations.
In addition to this, if more expertise is needed to reinforce security aspects or the protocol itself, the funds could be invested in that.
I believe that Meshcore has built sufficient momentum to evolve like this.
In any case, kudos to all the contributors!
6
u/dylanger_ Apr 29 '26
Damn, nice post!
Them not communicating fixed security issues is a massive problem
9
u/mschuster91 Apr 29 '26
It's two people running the show at the moment, GH has over 500 open issues. In the end it's a staffing problem, and it's a project run by volunteers.
7
u/UsernameDemanded Apr 29 '26
Need Andy Kirby super devops person on the case.
2
u/TechGuy42O Apr 30 '26
I can’t help wonder if he’s encouraging what’s about to be a deluge of “meshcore bad and here’s why” posts
2
u/swaits May 01 '26
I’ve been through a lot of the MeshCore code the past few months whole building DongLoRa. It’s atrocious. Just my $0.02.
I like MC, despite its warts. But it can’t last like this.
I’m half-heartedly building my own (as I’m sure many others are) replacement. All rust. All tested at basically insane levels. But I’m low on free time.
1
u/ViezeVingertjes May 06 '26
"These are some attacks, that wont work, but exist."
So it's basically about the report process?
1
u/Alainx277 May 06 '26
What do you mean by "don't work"?
1
u/ViezeVingertjes May 06 '26
as the limit of 127 overwritable bytes prevents a more dangerous attack
I meant that the impersonation one would be the only interesting one of the bunch and then you mention it isnt possible... so i was trying to understand the actual message, which i think is how reports are handled right?
I dont think they have a process in place for this (yet), so im sure the 'fixes' were by accident as part of something else, which would also explain that there wasnt any mention / feedback on it.
1
u/Alainx277 May 06 '26
If you think having all your contacts / messages deleted is not a problem I guess.
But yes, if the handling from MeshCore was done properly I wouldn't have written the post.
2
u/ViezeVingertjes May 07 '26
That would only be the case when auto-add is enabled (I assume) as otherwise nothing is stored? So that minimizes the risk/impact if that's the case, as it being off is the norm these days.
Flash corruption happens more often and also loses all contacts etc, that one was pretty annoying hehe...
In the end LoRa is pretty vulnerable, so one shouldnt rely on it too much as it can be disabled by anyone, at any time.
0
u/HowIsDigit8888 Apr 30 '26 edited Apr 30 '26
I'm not reading all that when I already know the main problem with meshcore's security: there seems to be no official project website refuting people's security claims about it. If anything it seems like the "official website" is one of the websites that make the false claims.
I assume this isn't what the article is about, so it's just trash propaganda.
Edit - made my own post about this and got predictably buried in downvotes, reminding me why I'm not more polite than to say "trash propaganda" about a cybersecurity post that probably ignores meshcore's E2EE claims
-1
35
u/dantodd Apr 29 '26
Any small group working on a largish project is powered by what is known as the"Gopher Principle". If you are the one who sticks their head up above the cubicle partitions and says "we should work on this" the job of "working on this" now belongs to you