View previous topic :: View next topic |
Author |
Message |
russellD n00b
Joined: 07 Oct 2014 Posts: 55 Location: 28.5797S,153.338 E
|
Posted: Fri Oct 27, 2023 4:19 am Post subject: Smokeping status on Gentoo? |
|
|
Hi Gentoo Brains Trust,
This tool has been suggested as a way to check network perfomance.
https://oss.oetiker.ch/smokeping/
However Smokeping 2.7.3-r1 has been pulled from Gentoo tree for about a year since it was found to have a serious vulnerablity.
GLSA: https://security.gentoo.org/glsa/202209-08
Bugzilla: https://bugs.gentoo.org/602652
Smokeping is now 2.8.2 https://oss.oetiker.ch/smokeping/pub/
This version is available ebuild is available for Gentoo as an overlay from oubliette
https://gpo.zugaina.org/net-analyzer/smokeping
Few questions about this!
1) is this GLSA due to smokeping code itself or is this the ebuild wrapper?
2) Maybe this could be ok in a docker container or a vm?
3) Not having the skills to write, debug or pentest this, wondering what you might suggest?
4) Maybe there is another tool to do this job?
Thanks in advance for your thoughts!
- r |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21638
|
Posted: Fri Oct 27, 2023 2:01 pm Post subject: |
|
|
- According to the linked bug report, the GLSA is due to the init script.
- It is only safe if you trust the smokeping user with full root privileges, since that is what the user can obtain by exploiting this. If your environment somehow guarantees that the smokeping user will never try to exploit this, or that giving it root privileges would be harmless, then a contained environment could work. In practice, guaranteeing that seems very difficult, so I cannot see Gentoo restoring this package without a proper fix.
- Find someone with those skills, spend the time to develop them, or find some other tool.
- I am not aware of one.
From a quick read of the oubliette overlay, it looks like the init script it uses was modified, but after reading the original bug report, I am not convinced that the modifications are sufficient to fix the problem. The use of --no-dereference closes one hole, but the hard link based exploit would likely still work.
Also, that dump function looks suspicious to me. It has insufficient quoting, so files with odd names can cause unwanted behavior. I do not see an obvious way to make it exploitable, but I have not tried very hard.
You could probably be safe if you remove both the dump and restore functions from the init script. This may or may not remove too much functionality for your use case. |
|
Back to top |
|
|
russellD n00b
Joined: 07 Oct 2014 Posts: 55 Location: 28.5797S,153.338 E
|
Posted: Sat Oct 28, 2023 12:18 am Post subject: |
|
|
Hi Hu,
Thank you for taking the time for your detailed and thoughtful reply.
Much appreciated.
- r |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|