FreeBSD-SA-26:06.tcp - remote DoS

Hi,

I was wondering why we don't see more online coverage of FreeBSD-SA-26:06.tcp

III. Impact

If an attacker is either on path with an established TCP connection, or can
themselves establish a TCP connection, to an affected FreeBSD machine, they
can easily craft and send packets which meet the challenge ACK criteria and
cause the FreeBSD host to leak an mbuf for each crafted packet in excess of
the configured rate limit settings i.e. with default settings, crafted packets
in excess of the first 5 sent within a 1s period will leak an mbuf.

To me this reads as if you just need to flood a system with TCP packets that trigger the challenge ACK to DoS it within seconds. Any system with sshd, http(s) or any other tcp service exposed to the world is vulnerable. Did I get this right? Pretty serious! Why is this not talked about more?
 
Sure. Just wondering why this doesn't show up anywhere. Serious software vulnerabilities normally are on tech news sites and blogs. So I was wondering if my understanding is wrong (not instant DoS) or if it is really basically ignored by the crowd.
 
Hi,

I was wondering why we don't see more online coverage of FreeBSD-SA-26:06.tcp

To me this reads as if you just need to flood a system with TCP packets that trigger the challenge ACK to DoS it within seconds. Any system with sshd, http(s) or any other tcp service exposed to the world is vulnerable. Did I get this right?

I would say, just try it out.

After all it's only a DoS, and I'm wondering anyway what makes the difference between a DoS, or software failing due to coding sloppiness, or software failing due to installing an exploitable bug disguised as a fix.
 
I would say, just try it out.

After all it's only a DoS, and I'm wondering anyway what makes the difference between a DoS, or software failing due to coding sloppiness, or software failing due to installing an exploitable bug disguised as a fix.
Are you serious?

If it only takes seconds to DoS a machine it could easily make you lose access to it for an extended period of time. ssh is TCP.
 
Are you serious?
Sure I am.

If it only takes seconds to DoS a machine it could easily make you lose access to it for an extended period of time. ssh is TCP.

I know. This can happen, and it has happened to me already.

When my site went repeatedly offline, I looked into it, did the forensics, found the problem in the code, fixed it, and posted the fix in a bug report[1]. Now do You see anybody giving a damn about it? I do not.

Then again, three days ago my site went offline. So when I came back home (I was away caring for elderly relative), what I finally found this time was a bug, not a serious bug, but one created out of sloppiness. Certainly that can happen, in fact it happens all the time, so let's see how long it may take until this gets fixed, while others may run into the same problem.[2]

Then on the way of testing the fix, I ran into a network failure warning. It came out to be just a wrong, bogus warning, created by sloppiness. Sure this is harmless, but irritating when you look for an actual problem. This one has already a PR, open for a couple of months.[3]

And now for the whopper: For two months now I am searching and analyzing why my databases do repeatedly fail the application and coredump. I twist my mind and get grey hair, because I cannot make out a logical explanation, the bug slips from analytical localization. The database guys recommend upgrade (sure, one can always do that, it doesn't cost them anything), the forum suggests a hardware flaw (which is unlikely but cannot easily be ruled out). So I am at the end of my wits and at the brink of despair - with the bug appearing irregularly and only after days or weeks there is not much further that could be done.
But now it comes out that this bug might be (not fully confirmed yet, but likely [4]) introduced by a botched security update!

A so called "errata fix" (that goes along the channel of security advisories and cannot separately be opted-out), which actually isn't an errata fix (because I understand an errata fix as something that replaces a clearly defined error with a clearly defined correction, without side-effects), but rather some coding experiment by whatever mad scientists, is apparently writing the memory that is in active use by my databases, with random pages of garbage!

In the forum was stated that a bug at this place is exploitable, and anyway I would consider it almost certain that it can potentially lead to silent data corruption (which then is a real problem, compared to some DoS).
And this gets fed onto us through the security advisory channel which everybody installs immediately into production! I do not know how there is decided what becomes an errata fix (I have seen enough things that should normally be errata, and weren't) but there is certainly something wrong with the proceedings.

So then, all this within 72 hours. And when I finally came to the conclusion that a general attitude change is utterly needed, funnily just in that moment the forum gets hacked, precisely to put a proof onto my point. (It was enlightenment in fullness, expanding to the higher plane of socio-cultural disregard - and I loved the music).

Now think about it: when the upstream tells You that there is an issue, You wonder why there isn't enough worrying. But all the issues we actually run into every day, they don't matter to no one.

It's just like when big-brother tells you now it's time to worry about the evil hackers, then everybody worries and does the rituals (installing advisories). Or when they tell you now its time to hate the evil russians, then everybody hates and does the rituals (paying for nuclear bombs). All just puppets on a string, like hate-week in 1984. You're only doing what you get told.

[1] PR289661
[2] PR294114
[3] PR292604
[4] PR294039
 
Back
Top