- cross-posted to:
- Technology@programming.dev
- cross-posted to:
- Technology@programming.dev
cross-posted from: https://programming.dev/post/37090037
Comments
You must log in or # to comment.
Completely unrelated, but I just remembered that I have a server too. It’s funny how often I forget this.
It doesn’t run apache but I haven’t updated nginx in months…
Honestly, apart from the report being potentially wrong, the researcher seems pretty entitled as well. Like good intentions and all that, but he’s given him a week to fix the issue, usual practice in responsible disclosure are 90 days. We’re not talking about a company here, it’s some single random dude providing the app.
This really sounds like some personal issue written down for public drama, while making himself ridiculous for not knowing his own shit properly.
Security researchers feel entitled to use any kind of practice that does not comply with the security best practice homonculus to barge into the affairs of others, anyone found in default MUST remedy the situation of discontinue operations immediately, the security researcher has graced the community with his works and now that a flaw has been found it MUST be remedied and the security researcher is to be rewarded and adulated for his diligence and high moral standing !
This is an Apache server version error it takes 5 minutes to fix.
So fucking what? He is not being paid in any kind, and anything he does on that project is volunteer work. If he was not able to do anything on that project due to regular work, vacation, personal issues, or the simple fact that he didn’t want to?
If you don’t pay for a service, you don’t get to decide what people do, deal with it
Well on one hand sure.
On the other hand, detrimental reliance is a tort and if someone is relying on an app for a specific safety function, the app could be civilly liable if it fails it’s function in some way.
Imagine if you had this attitude about an insulin use tracker/calculator, that sometimes gave wildly wrong insulin dose numbers.
Maybe down the road, it’s decided that aiding and abetting ICE is a crime, and providing misinformation intentionally or unintentionally is a criminal act. App developer dude could be criminally liable if he knew or ought to have known he had vulnerabilities. You know, in your New Nuremberg trials that you are going to get sometime in the next decade or so.
That’s not to say the researcher is in the clear, the timeline is too tight for his end of this to be a responsible disclosure.
Without providing more details, I also discovered that his server is running outdated software with known vulnerabilities.
I was intentionally vague because I knew that his server was vulnerable at the time of writing, and I didn’t want anyone to exploit one of these vulnerabilities before he had a chance to fix it.
Also, this is not vague, profiling techniques exist, and it puts a clear target on the iceblock servers.
On the other hand, detrimental reliance is a tort and if someone is relying on an app for a specific safety function, the app could be civilly liable if it fails it’s function in some way.
Yes, if the app would be any kind of official tool.
Imagine if you had this attitude about an insulin use tracker/calculator, that sometimes gave wildly wrong insulin dose numbers.
Yes, and that’s why regulations for those kinds of things exist, that prevent those things. There is no regulation for the ice tracker.
Maybe down the road, it’s decided that aiding and abetting ICE is a crime, and providing misinformation intentionally or unintentionally is a criminal act. App developer dude could be criminally liable if he knew or ought to have known he had vulnerabilities. You know, in your New Nuremberg trials that you are going to get sometime in the next decade or so.
If down the road a regulation would happen for, app developer dude would be forced to either comply or to stop operations.
Wouldn’t need so much regulation if things were just well reasoned and fit for purpose. Or if they would stop only pretending to be those.
No matter how well reasoned, allegedly fit for purpose or how much something pretends to be it, we shouldn’t be trusting those promises, especially not from people we don’t know. That does not end well neither for the free candy van nor for cybersecurity. Trust like that has been responsible for a lot of attacks over varying vectors and for projects going wrong.
Well yeah, that just requires a consensus on what is trustworthy. There are some things that are trustworthy, and you need to have some way to identify that, if you are going to protect yourself.
But that just shifts the blame to the user, who is a non expert, and we don’t really have good ways to identify safe software products. There’s stuff like CSA for physical products. It’s short-sighted to say “well if you don’t know, use nothing”, because that’s not going to happen.
You don’t like it, don’t use it. Lol
I’m also in Canada. Just because I’m not using it, I’m not going to give either of these guys a pass on maybe hurting people, or even putting them at risk of harm.
This security researcher is just wrong. The version of apache running is likely in a ‘stable’ release where critical CVEs are fixed by back-porting patches to the same older version of software. Also, if I’m reading correctly, the vulnerability he cites is dependent on malicious behavior of apps hosted behind the vulnerable server. His would likely not meet this criteria, so the vulnerability does not affect his use case.
It is the blogger, IMO, who is participating in ‘theater’. A little knowledge is a dangerous thing.
Well the interesting thing here is that you took the time to type that out while he just blocked the person trying to report a security vulnerability.
The example CVE linked in the article is plausible, though. The server was reportedly running 2.4.57 and the CVE was fixed in 2.4.60, so it’s definitely present in the software. Whether it would actually be exploitable is a different question.
Overall, I don’t get your point about stable releases and backports. Yes, security patches are backported, but that results in a new release (2.4.60 in this case) which still has to be updated to. It’s not like you can just stay on 2.4.57 and magically still have the fix, that’s just not how software versioning is done.
The server was reportedly running 2.4.57 and the CVE was fixed in 2.4.60, so it’s definitely present in the software.
Overall, I don’t get your point about stable releases and backports.
Clearly. Hint: it’s what Enterprise Linux has done for 20 years.
Distros may not update software versions when backporting some things, meaning they add a suffix they control to the version e.g. 2.4.57-ubuntu1.2 whatever, but the version reported by the software itself might still be 2.4.57.
It depends on the release process. I was also confused once I was asking myself why the repo was reporting a CVE as fixed when it still showed the old version.
This dude seems like an A-hole and the article doesnt even mention, prior to the “update,” anything about ICEBlock’s response to his report so where does he get the nerve titling his little essay as he did?
This whole thing is written as if this guy has a personal vendetta against ICEBlock or its creator (“his infuriating HOPE talk” “activism theater”) and is light on the facts while heavy on emotion.
The best part is in the comments.
You’re right, he might have a backported patch and not be vulnerable to any of the several CVEs for this version of Apache. But also, his server might be really easy to hack. Rather than confirming that his server is secure, he blocked me when I reported the issue.
“Oh no, someone blocked me after I accused them of something I possibly made up”
This smells more like a Honeypot every day.
Seems like a pretty shitty report in the first place, so that seems fair.
Feel like you can use local meshtastic networks to accomplish the same thing.
Having played with it a bit, I have very low hopes for Meshtastic.
Being UHF it’s very line of sight, and things like trees absorb the signal significantly. They like to talk about long range, but it really isn’t.
Meshtastic doesn’t really do intelligent routing, so it’s not great as a single large public net.
Meshtastic has a lot of little features like telemetry and such which are half-baked and broadcast on the Primary “channel.” Settings to send automatic or telemetry data over secondary channels is absent in the very half-baked software are of course missing.
It’s less secure than shouting in the street. Looking at the design of the thing, it looks like it’s a man-in-the-middle attack that’s had a chat app built around it.
And you’re not going to get normies to adopt it. It’s a garbagefuck user unfriendly chat app that you need to spend $50 on a little radio to even use, to talk to…nobody. I’ve seen the idea of “Let’s use it to communicate during our hike!” I can think of fewer practical ways to do that, because now you have to have the Meshtastic node and a phone with you, if one or the other battery dies you’re fucked, and it’s possible you’d be out of radio range of your partners before you’re out of shouting range. Somebody’s gonna walk out into the woods with a meshtastic node, fall into a hole and their body will never be found.
Idk with the mountainous terrain of my state its fine. It covers the entire city with all the relays we have and they are solar powered. I will say you are right about the security. Its literally only safe because no one knows about it.
I live in an East coast pine forest where the average urethra has longer range than sub-watt UHF. What range testing I’ve done with the two nodes I own shows I can get about 3 blocks with one of my nodes on my roof. Around here, you’d need adoption at a truly impossible scale to get any use out of LoRa as an infrastructure protocol.
I know of three projects that use LoRa as the carrier technology: Meshtastic, Meshcore and even Reticulum (which isn’t strictly LoRa but I’ve seen it extended across LoRa). Meshtastic is probably the worst, and most popular, of the lot.
We really fucked up letting corporations control the internet.
Meshtastic is fine for a small network but people are using it with the intention of building a city-wide mesh network and it’s failing miserably. There would have to be big changes in Meshtastic before it’s viable in such an environment. Meshcore however seems to show promise. The only downside being the need for repeater nodes since clients don’t repeat. I’m seeing a little adoption of Meshcore locally.
There are attempts to make state-wide meshes, there’s one in North Carolina. Most of the traffic on this mesh? “Morning mesh!” --no answer-- Most of the conversations you see between members? On Discord. Probably because Discord actually works.
I dig the idea of a communication network in which individuals can own the infrastructure. This doesn’t seem to be it, though.
Uhhhh yes and no? You can’t send anything but text over Meshtastic. You’re also dependent on other people using it. And it’s also extremely unreliable. Further you’d probably want a specific thread for notifications which not only would you have to convince people to join but it’d probably be filled with crosstalk since there are no moderation capabilities.
Plus it would be susceptible to the same ignorant/malicious reports as this app.
Looking more and more like Coqui is the better app.
