# FreeBSD patch vs kernel patch level



## tux2bsd (Dec 4, 2022)

```
freebsd-version -r : 13.1-RELEASE-p3
freebsd-version    : 13.1-RELEASE-p5
```

From the running headless OS, what command line tool do you run that confirms that kernel p3 is the correct kernel for p5?


----------



## zirias@ (Dec 4, 2022)

None. If you really don't trust freebsd-update(8), read the errata notices and security advisories, they will tell whether the kernel is affected.

But then, in the upgrade process, the kernel is updated _first_. I really don't see any reason not to trust freebsd-update(8). `freebsd-version` is enough to verify a correct update.


----------



## tux2bsd (Dec 5, 2022)

How did you decide to defend freebsd-update on the basis of trust?

I'll try another way.  What flags the need for a reboot without human reading?


----------



## zirias@ (Dec 5, 2022)

If you're too lazy to read, just reboot. 
(yes, checking `freebsd-version -k` against `freebsd-version -r` involves, uhm, _reading_...)


----------



## Alain De Vos (Dec 5, 2022)

You can have a running-kernel X and boot-kernel X. 
Then you perform freebsd-update , the running-kernel will still be X but the boot-kernel will be Y.
After reboot the running-kernel & boot-kernel will be Y.


----------



## SirDice (Dec 5, 2022)

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


----------



## tux2bsd (Dec 5, 2022)

zirias@ managed the right answer on the second attempt.  A pity about his arrogance.


----------



## tux2bsd (Dec 5, 2022)

Alain De Vos said:


> You can have a running-kernel X and boot-kernel X.


thanks, yeah the man page says installed kernel (aka boot kernel) but I must have overlooked it


----------



## tux2bsd (Dec 5, 2022)

When the system is up to date it takes me this amount of seconds (/usr/bin/time) to validate there is nothing new:


```
#Raspberry Pi 3B (very slow IO)
/usr/bin/time /usr/local/bin/update.sh
        1.54 real         0.67 user         0.27 sys
```

That means check for freebsd-update and pkg (pkg is naturally fast here).

Of course, when there are updates available it all takes the regular times (and that is when the running/installed kernel comparison becomes useful to me because my script will now just reboot if it sees that change).


----------



## zirias@ (Dec 5, 2022)

Check your attitude, like, check what people might think about your first response here.


----------



## Alain De Vos (Dec 5, 2022)

Different persons on this forum have different levels of knowledge.
When you have higher knowledge sometimes we can forget once we had lower knowledge and understood things wrong (which is normal) (afterwards there is an aha moment, now i understand)


----------



## tux2bsd (Dec 5, 2022)

zirias@ said:


> Check your attitude, like, check what people might think about your first response here.


Why have you decided to derail yet another thread?


----------



## tux2bsd (Dec 5, 2022)

Alain De Vos said:


> Different persons on this forum have different levels of knowledge.
> When you have higher knowledge sometimes we can forget once we had lower knowledge and understood things wrong (which is normal) (afterwards there is an aha moment, now i understand)


Nothing to do with knowledge or understanding, simply didn't see what I was looking for so I asked.


----------



## tux2bsd (Dec 5, 2022)

As I was saying...

When the system is up to date it takes me this amount of seconds (/usr/bin/time) to validate there is nothing new:


```
#Raspberry Pi 3B (very slow IO)
/usr/bin/time /usr/local/bin/update.sh
        1.54 real         0.67 user         0.27 sys
```

That means check for freebsd-update (freebsd-update-probe) and pkg (pkg is naturally fast here).

Of course, when there are updates available it all takes the regular times (and that is when the running/installed kernel comparison becomes useful to me because my script will now just reboot if it sees that change).


----------



## Alain De Vos (Dec 5, 2022)

The more time i spend on this forum the more i found my knowledge increasing. But i always try not to be personal in my answers. I find politeness a nice value.


----------



## Profighost (Dec 5, 2022)

First he asks:"What to do without reading?"
Answer:"If you don't want to read..."
Him again:"You're arrogant."

This guy suffers from a complete mismatch of self- and external perception.
He simply does not realize how he acts.

He hits others - having a reasonable expert's conversation, trying to help him - directly in the face without any reason and no forewarning
and then most aggressively repells any reaction he provocated himself.

I start to believe he's on drugs (cocaine?), but anyway really needs professional help.


----------



## tux2bsd (Dec 5, 2022)

Alain De Vos said:


> The more time i spend on this forum the more i found my knowledge increasing. But i always try not to be personal in my answers. I find politeness a nice value.


Stop polluting a simple thread with your banality.


----------



## tux2bsd (Dec 5, 2022)

As I was saying...

When the system is up to date it takes me this amount of seconds (/usr/bin/time) to validate there is nothing new:


```
#Raspberry Pi 3B (very slow IO)
/usr/bin/time /usr/local/bin/update.sh
        1.54 real         0.67 user         0.27 sys
```

That means check for freebsd-update (freebsd-update-probe) and pkg (pkg is naturally fast here).

Of course, when there are updates available it all takes the regular times (and that is when the running/installed kernel comparison becomes useful to me because my script will now just reboot if it sees that change).


----------



## tux2bsd (Dec 5, 2022)

Profighost said:


> First he asks:"What to do without reading?"
> Answer:"If you don't want to read..."


A human isn't present to do the reading...  in fact, if you had read on you would have realised.  But you're a troll account which I have blocked (I think you're the only one I blocked) - I just got curious this time.  An interesting amount of defamation in your post but we all know that the moderators are selectively blind.


----------



## SirDice (Dec 5, 2022)

You're treading on thin ice again tux2bsd


----------



## zirias@ (Dec 5, 2022)

tux2bsd said:


> A human isn't present to do the reading...


Let that sink in...  *scnr*
(I'm done with this thread.)


----------



## tux2bsd (Dec 5, 2022)

zirias@ said:


> Let that sink in...  *scnr*
> (I'm done with this thread.)


You don't know the use case.  Remember, I never asked YOU to respond.


----------



## tux2bsd (Dec 5, 2022)

Profighost said:


> First he asks:"What to do without reading?"
> Answer:"If you don't want to read..."
> Him again:"You're arrogant."
> 
> ...


SirDice I think Profighost must be an alt account of yours given you sanction such content and instead move to threaten the recipient of defamation... strange behaviour.


----------



## SirDice (Dec 5, 2022)

Sure.


----------



## Alain De Vos (Dec 5, 2022)

I'm done on this thread too. Have a nice day.


----------



## wolffnx (Dec 5, 2022)

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@ (Dec 5, 2022)

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 (Dec 5, 2022)

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


----------



## Alain De Vos (Dec 5, 2022)

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 (Dec 5, 2022)

Aaron_VanAlstine said:


> 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 (Dec 5, 2022)

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


----------



## SirDice (Dec 5, 2022)

Alain De Vos said:


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


Not impossible, just very, very unlikely.


----------



## zirias@ (Dec 5, 2022)

SirDice said:


> 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 (Dec 5, 2022)

Still i feel less vulnerable than when i used Windows.


----------



## smithi (Dec 5, 2022)

SirDice said:


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





zirias@ said:


> 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 (Dec 5, 2022)

smithi said:


> 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@ (Dec 5, 2022)

smithi said:


> 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 (Dec 5, 2022)

zirias@ said:


> 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@ (Dec 10, 2022)

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 (Dec 11, 2022)

SirDice said:


> 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.


----------

