FreeBSD patch vs kernel patch level

[wolffnx]

tux2bsd respect above all, no one here will disrespect you,in this or another post
beyond if your problem is solved or not, in this forum everyone will help you,from the beginners to the "gurus"
but for me,with your actitude you deserve a non answer and dead post

 

[zirias@]

wolffnx agreed, but better just leave it. In the aftermath, what this guy got furious about (once again) was probably me suggesting "laziness" . Sure, that's not "nice", but then, what do you make of a request to know stuff without reading? It's a bit ridiculous. And still no match for the aggressive style of this particular member. Well, I promised I'm out of here, sorry

 

[Aaron_VanAlstine]

I saw something about a ping vulnerability on Twitter and immediately upgraded my headless box. It sounded like a serious vulnerability.

 

[Alain De Vos]

CVE-2022-23093 | FreeBSD Ping pr_pack stack-based overflow

A vulnerability was found in FreeBSD 12.3/12.4/13.0/13.1. It has been rated as critical. The identification of this vulnerability is CVE-2022-23093. It is recommended to apply a patch to fix this issue.

vuldb.com

 

[SirDice]

I saw something about a ping vulnerability on Twitter and immediately upgraded my headless box. It sounded like a serious vulnerability.

Only if you ping a bad (malicious) host.

 

[Alain De Vos]

Imagine if a "google" server is compromised ...

 

[SirDice]

Imagine if a "google" server is compromised ...

Not impossible, just very, very unlikely.

 

[zirias@]

Only if you ping a bad (malicious) host.

Or if you ping an innocuous host and you're hit by a MITM attack. But yes, you have to ping "something" in order to be hit.

Edit: The SA claims no workaround was available. I'd suggest rm /sbin/ping

 

[Alain De Vos]

Still i feel less vulnerable than when i used Windows.

 

[smithi]

Only if you ping a bad (malicious) host.If

Or if you ping an innocuous host and you're hit by a MITM attack. But yes, you have to ping "something" in order to be hit.

Edit: The SA claims no workaround was available. I'd suggest rm /sbin/ping

Meaning, no workaround short of running freebsd-update, since ping was already patched there when the SA was announced?

( not everyone understands that clowns are joking <&^}= )

 

[SirDice]

Meaning, no workaround short of running freebsd-update, since ping was already patched there when the SA was announced?

P5 included the fixed ping(1), it also included some fixes for p4 that broke Kerberos.

 

[zirias@]

Meaning, no workaround short of running freebsd-update, since ping was already patched there when the SA was announced?

Uhm, "no workaround available" in an SA just means there's no way to avoid the problem short of updating. I'd argue just removing ping would avoid the problem. Yep, not really a recommended thing to do.

 

[wolffnx]

Uhm, "no workaround available" in an SA just means there's no way to avoid the problem short of updating. I'd argue just removing ping would avoid the problem. Yep, not really a recommended thing to do.

I dont know anything about the vulnerability,but the alternatives? hping3,fping? for the moment I say

 

[cracauer@]

The ping vulnerability isn't that bad. By the time where the bug can occur it is in restricted capability mode (which it is to guard against exactly this situation). So while it can execute arbitrary code it can't freely execute system calls, so apart from taking CPU time there isn't much that it can do to alter the system with a backdoor or somesuch.

I also don't understand why many articles say there is no workaround apart from updating. For most practical uses a "rm `which ping`" will do fine.

 

[msplsh]

p4 and p5 didn't involve the kernel, so it hasn't been updated.

Determining this seems to require wading through p4 and p5 changelogs, so that mismatch can be kind of worrisome if you are checking on things mechanically. I could understand why this could be a bother.