Spurious reboot notifications caused by libssl upgrades.

[i am not what i am]

The postinst script for libssl0.9.8 currently has a bug where it sends a reboot notifcation whenever libssl is configured. So reconfiguring libssl0.9.8 or even just installing libssl0.9.8 will result in a reboot notification. Sending of the reboot notification should definitely be moved inside the upgrading guard. The correct fix is likely to move it inside a version comparison guard for particular important updates like Colin suggests below -- this is what every other standard package using notify-reboot-required does.

[Colin Watson (cjwatson)]

Your tone in this report is not necessary. Please moderate it.

This does make sense on *some* upgrades; we can't feasibly restart all libssl clients automatically, which may include a good chunk of the desktop, and this may result in client-side security holes sticking around unnoticed. It's certainly possible to continue without rebooting - for instance, you can ensure that all services that use libssl are restarted, and ensure that all users log out and back in again - but this may not necessarily be advisable depending on the level of expertise of the user and on the severity of the security update.

That said, I think it's probably a bit much to display the reboot-required notification on every libssl0.9.8 upgrade, as now happens. That wasn't quite what I meant in bug 91814. I think we should move that inside the dpkg --compare-versions guard so that it only happens on certain serious upgrades, and perhaps update the version in that guard to cover the recent random number generator vulnerability. Luke, what do you think?

[i am not what i am (iamnotwhatiam-deactivatedaccount)]

I have semi-moderated it. You are very fast to respond. Thank you for providing some clarity. Hopefully reboots that are not required can be removed... (in the future). Or perhaps we should display some information about what a user should reboot --- if the user wants to see it. (perhaps just a reference to a command which can pull the reason up).

[nutznboltz (nutznboltz-deactivatedaccount)]

Is it really that hard to find what programs are running and linked to OpenSSL libraries?

Wouldn't a slightly more sophisticated version of this do it?

sudo lsof | grep ' mem .* /lib/libcrypt'

[Tim Abbott (tabbott)]

I've changed the description to more precisely characterize the actionable problem here, namely a buggy postinst script that sends spurious reboot notifications.

[Damian Yerrick (tepples)]

Still seen on my 8.04 development workstation and my 10.10 laptop.

Based on Colin Watson's comment, I guess it should work like this:
1. Automatically restart services that depend on SSL, just as we do
   when the services' packages are upgraded.
2. Give a "logout recommended" notice (not a "reboot required" notice)
   to any user using a desktop environment that depends on SSL.
3. Give an "application restart recommended" notice to any user using
   an application that depends on SSL, much as we currently do after
   upgrading Firefox.

Logging out and back in is disruptive to the end user's work flow,
but at least doing so is less disruptive than restarting, especially
on a machine that takes a long time to POST and that is suspended
more often than shut down. I almost feel like reporting this as a
paper cut.

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssl - 1.0.0e-2ubuntu1

---------------
openssl (1.0.0e-2ubuntu1) oneiric; urgency=low

  * Resynchronise with Debian, fixes CVE-2011-1945, CVE-2011-3207 and
    CVE-2011-3210 (LP: #850608). Remaining changes:
    - debian/libssl1.0.0.postinst:
      + Display a system restart required notification bubble on libssl1.0.0
        upgrade.
      + Use a different priority for libssl1.0.0/restart-services depending
        on whether a desktop, or server dist-upgrade is being performed.
    - debian/{libssl1.0.0-udeb.dirs, control, rules}: Create
      libssl1.0.0-udeb, for the benefit of wget-udeb (no wget-udeb package
      in Debian).
    - debian/{libcrypto1.0.0-udeb.dirs, libssl1.0.0.dirs, libssl1.0.0.files,
      rules}: Move runtime libraries to /lib, for the benefit of
      wpasupplicant.
    - debian/patches/aesni.patch: Backport Intel AES-NI support, now from
      http://rt.openssl.org/Ticket/Display.html?id=2065 rather than the
      0.9.8 variant.
    - debian/patches/Bsymbolic-functions.patch: Link using
      -Bsymbolic-functions.
    - debian/patches/perlpath-quilt.patch: Don't change perl #! paths under
      .pc.
    - debian/rules:
      + Don't run 'make test' when cross-building.
      + Use host compiler when cross-building. Patch from Neil Williams.
      + Don't build for processors no longer supported: i486, i586 (on
        i386), v8 (on sparc).
      + Fix Makefile to properly clean up libs/ dirs in clean target.
      + Replace duplicate files in the doc directory with symlinks.
  * debian/libssl1.0.0.postinst: only display restart notification on
    servers (LP: #244250)

openssl (1.0.0e-2) unstable; urgency=low

  * Add a missing $(DEB_HOST_MULTIARCH)

openssl (1.0.0e-1) unstable; urgency=low

  * New upstream version
    - Fix bug where CRLs with nextUpdate in the past are sometimes accepted
      by initialising X509_STORE_CTX properly. (CVE-2011-3207)
    - Fix SSL memory handling for (EC)DH ciphersuites, in particular
      for multi-threaded use of ECDH. (CVE-2011-3210)
    - Add protection against ECDSA timing attacks (CVE-2011-1945)
  * Block DigiNotar certifiates. Patch from
    Raphael Geissert <email address hidden>
  * Generate hashes for all certs in a file (Closes: #628780, #594524)
    Patch from Klaus Ethgen <email address hidden>
  * Add multiarch support (Closs: #638137)
    Patch from Steve Langasek / Ubuntu
  * Symbols from the gost engine were removed because it didn't have
    a linker file. Thanks to Roman I Khimov <email address hidden>
    (Closes: #631503)
  * Add support for s390x. Patch from Aurelien Jarno <email address hidden>
    (Closes: #641100)
  * Add build-arch and build-indep targets to the rules file.

openssl (1.0.0d-3) unstable; urgency=low

  * Make it build on sparc64. Patch from Aurelien Jarno. (Closes: #626060)
  * Apply patches from Scott Schaefer <email address hidden> to
    fix various pod and spelling errors. (Closes: #622820, #605561)
  * Add missing symbols for the engines (Closes: #623038)
  * More spelling fixes from Scott Schaefer (Closes: #395424)
  * Patch from Scott Schaefer to better document pkcs12 password options
    (...

[Anders Kaseorg (andersk)]

This bug is not fixed. It’s still the case that libssl1.0.0 generates a spurious reboot notification during reconfiguration, on initial installation, and on non-critical upgrades, as originally reported. The only change in 1.0.0e-2ubuntu1 is that this no longer happens at all on systems running /usr/bin/X (even for critical upgrades!).

Please reopen this bug report.

[Colin Watson (cjwatson)]

Agreed. It really doesn't make sense to issue the reboot-required notification when we aren't doing the whole restart-services dance. I'll look at the branch you proposed for this.

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssl - 1.0.0e-2ubuntu3

---------------
openssl (1.0.0e-2ubuntu3) oneiric; urgency=low

  * Only issue a restart required notification on important upgrades, and
    not other actions such as reconfiguration or initial installation.
    (LP: #244250)
 -- Anders Kaseorg <email address hidden> Tue, 04 Oct 2011 13:33:35 +0100

[Marc Deslauriers (mdeslaur)]

Actually, we do want a reboot notification when we issue security updates. When we issue security updates, we don't enter the major upgrade section, as we don't want the update to automatically restart services, but we do want the sysadmin to perform a planned reboot/service restart as the running services will be using a vulnerable openssl.

I'm upload a fix to move the notification to the upgrade section instead of the major upgrade section.

[Thomas Bushnell, BSG (tbushnell)]

On Tue, Oct 4, 2011 at 3:37 PM, Marc Deslauriers <
<email address hidden>> wrote:

> Actually, we do want a reboot notification when we issue security
> updates. When we issue security updates, we don't enter the major
> upgrade section, as we don't want the update to automatically restart
> services, but we do want the sysadmin to perform a planned
> reboot/service restart as the running services will be using a
> vulnerable openssl.
>
> I'm upload a fix to move the notification to the upgrade section instead
> of the major upgrade section.

No, this is fundamentally incorrect. This would be ok *only *if you had
some sensible isolation between servers and clients. It is ridiculous that
user workstations running no servers at all get told to reboot because of a
security change to ssl.

We had to engineer a whole system to prevent the reboot notifications from
being honored on our workstations because the have been so sloppily and
carelessly set, with incorrect reasoning like this.

*Any *library could need a security update; *any *library could have a
security update which is relevant to running services, and it is *not *correct
to force reboots on every package install merely because *sometimes *on *some
*systems it might be necessary for the security fix.

We do not force reboots when firefox gets a security fix, or sh, or ... and
that's the right thing. openssl is *not *different than the rest of these.

Thomas

[Marc Deslauriers (mdeslaur)]

We've already removed reboot notifications from openssl on desktops, I'm just talking about servers.

[Thomas Bushnell, BSG (tbushnell)]

How do you distinguish a server from a desktop, and what about servers that
don't run ssl-using daemons?

Thomas
On Oct 4, 2011 2:05 PM, "Marc Deslauriers" <email address hidden>
wrote:
> We've already removed reboot notifications from openssl on desktops, I'm
> just talking about servers.
>
> --
> You received this bug notification because you are a member of Goobuntu
> Team, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/244250
>
> Title:
> Spurious reboot notifications caused by libssl upgrades.
>
> Status in “openssl” package in Ubuntu:
> Fix Released
>
> Bug description:
> The postinst script for libssl0.9.8 currently has a bug where it sends
> a reboot notifcation whenever libssl is configured. So reconfiguring
> libssl0.9.8 or even just installing libssl0.9.8 will result in a
> reboot notification. Sending of the reboot notification should
> definitely be moved inside the upgrading guard. The correct fix is
> likely to move it inside a version comparison guard for particular
> important updates like Colin suggests below -- this is what every
> other standard package using notify-reboot-required does.
>
> To manage notifications about this bug go to:
>
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/244250/+subscriptions

[Marc Deslauriers (mdeslaur)]

Right now, the best way we have of determining if we're a server or a desktop is to check if X is running. It's not ideal, and suggestions are welcome.

We need a way for sysadmins to get notifications that some of the major automatic updates they are installing, such as openssl and the kernel, require services and/or the system to get restarted after a security update. The mechanism we have now is the reboot notification tool.

I agree that a lot of libraries can have security issues also, and in fact, most of the server packages will gracefully restart when they get security updates. For openssl, and a few other select libraries, things are different. Security issues in openssl usually are of importance for network servers, and automatically restarting all the running daemons isn't an option, especially since the server could be running software that wasn't installed from packages in the archive. In this case, the reboot notification indicates to the sysadmin that manual intervention is needed. If the sysadmin decides that nothing on his server is affected, he can simply remove the reboot notification file. Yes, this solution is far from perfect, but the alternative is to disable notifications completely, which is not a viable option.

I am completely open to suggestions on improving this process and having a discussion with you, outside of this bug, to have your ideas on how it could be done in a way which would satisfy the majority of our users.

[Thomas Bushnell, BSG (tbushnell)]

On Wed, Oct 5, 2011 at 12:54 AM, Marc Deslauriers <
<email address hidden>> wrote:

> Right now, the best way we have of determining if we're a server or a
> desktop is to check if X is running. It's not ideal, and suggestions are
> welcome.
>

I think my question is suggesting that there really isn't a principled
distinction between "desktop" and "server" for things like this.

> We need a way for sysadmins to get notifications that some of the major
> automatic updates they are installing, such as openssl and the kernel,
> require services and/or the system to get restarted after a security
> update. The mechanism we have now is the reboot notification tool.
>

It's the right tool, but the correct approach is the standard one: Debian
packages should do in-place upgrades, except the kernel. With libc much work
was spent figuring out what to restart and how, and it works. openssl should
do the same thing.

> I agree that a lot of libraries can have security issues also, and in
> fact, most of the server packages will gracefully restart when they get
> security updates. For openssl, and a few other select libraries, things
> are different. Security issues in openssl usually are of importance for
> network servers, and automatically restarting all the running daemons
> isn't an option, especially since the server could be running software
> that wasn't installed from packages in the archive. In this case, the
> reboot notification indicates to the sysadmin that manual intervention
> is needed. If the sysadmin decides that nothing on his server is
> affected, he can simply remove the reboot notification file. Yes, this
> solution is far from perfect, but the alternative is to disable
> notifications completely, which is not a viable option.

Not running X doesn't mean that someone is running ssl servers, right? Why
not look for ssl servers, specifically, and only if there are ssl servers
running, call for the reboot?

Thomas

[Damian Yerrick (tepples)]

The problem still exists. Xubuntu 11.10 on a desktop, the only application with an open window that is obviously using SSL is Firefox, the only update was for libssl and openssl, and Update Manager still tells me a reboot is required.

[Khaled Blah (khaled-blah)]

On Ubuntu 14.04 this bug still persists. Is there any reason why libssl would require different treatment than other libraries? I.e. why wouldn't it suffice to restart services depending on libssl or libcrypto?

[Marc Deslauriers (mdeslaur)]

@khaled-blah: please file a new bug, you are not supposed to see reboot notifications when openssl gets upgraded on a desktop system.

[Khaled Blah (khaled-blah)]

@mdeslaur: Thank you for your reply! Does that mean that it is supposed to happen on an Ubuntu server system?

[Marc Deslauriers (mdeslaur)]

@khaled-blah: yes, on a server, it should do the usual and add a reboot required blurb to the motd.

[Khaled Blah (khaled-blah)]

@mdeslaur: Again, thank you for your reply! Pardon my ignorance but I've never quite understood why that is - why is an update of libssl different from an update of other libs where you can simply restart the depending applications/daemons? And why is it different on a desktop? Maybe these questions require lengthy answers so if you could point me in a direction where I read up on these questions I'd be very grateful.

[Damian Yerrick (tepples)]

A web server is supposed to retrieve data from database, run application logic, write back to database if needed, write an HTML document or JSON object to output, and wait for the next request. Ideally, it's stateless between requests.

A desktop application, on the other hand, is more likely to have a lot of state in RAM that isn't persisted to the file system. In particular, you can't "simply restart" a web browser because when a browser restarts, it retrieves the HTML document open in each tab as if the user had navigated to it again. This incurs data loss in two ways:

1. If the user is offline, pages open in tabs for later reading will be replaced with "Cannot find server" error pages. (Chromium, for example, shows the "downasaur" minigame.) I often do this on my laptop so that I have something to read while riding the bus to work or wherever.
2. Several web applications, such as comment composition forms on Slashdot, lose DOM state if closed. When the browser navigates to the page again, the DOM is reset to what it was when the page was first opened, and the comment that the user was composing is lost. I imagine any webmail site that doesn't automatically save drafts in the background has the same problem, and even those that do save drafts will have a problem if the user is offline and the site doesn't use a Service Worker.