Now is the time to ensure you know what your surface area is for OpenSSL. Do you terminate SSL on your hosts? Do you have a loadbalancer that terminates SSL for you? Do you distribute OpenSSL to clients? Do you have network devices that have OpenSSL on them? These things are all important for you to know to be able to handle the response to whatever drops on the 19th correctly. Good luck!
Libs are always a pain to patch at the OS level, because you are not really sure what links against the lib, you can do some manual work but most often a reboot is way easier. Here is a pretty common pattern, that I use, if I cannot reboot right away. Doesn't hurt to go through the motions, then you have a pretty good idea of what needs to be done, stops the panic patch work ;)
On RHEL/CentOS, you can use needs-restarting, to tell you what processes need restarting after a lib update.
Helps to work through this manually, wrap your head around what needs to be done, then you can push that into automation tools if you have a large enough infrastructure. Here's a screencast about the pattern for anyone interested in learning more.
high severity issues. This includes issues affecting common configurations which are also likely to be exploitable. Examples include a server DoS, a significant leak of server memory, and remote code execution. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control, and significantly quicker if there is a significant risk or we are aware the issue is being exploited.
4 comments
[ 4.6 ms ] story [ 26.0 ms ] threadOn RHEL/CentOS, you can use needs-restarting, to tell you what processes need restarting after a lib update.
On Debian/Ubuntu, you can use checkrestart, to tell you what processes need restarting after a lib update. Helps to work through this manually, wrap your head around what needs to be done, then you can push that into automation tools if you have a large enough infrastructure. Here's a screencast about the pattern for anyone interested in learning more.[1] https://sysadmincasts.com/episodes/44-patching-the-ghost-gli...
https://www.openssl.org/about/secpolicy.html
high severity issues. This includes issues affecting common configurations which are also likely to be exploitable. Examples include a server DoS, a significant leak of server memory, and remote code execution. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control, and significantly quicker if there is a significant risk or we are aware the issue is being exploited.