new f19/f20 images

[drago01]

On Thu, Apr 17, 2014 at 4:31 PM, Chuck Anderson <cra at wpi.edu> wrote:
> On Thu, Apr 17, 2014 at 03:11:38PM +0200, drago01 wrote:
>> On Thu, Apr 17, 2014 at 3:02 PM, Chuck Anderson <cra at wpi.edu> wrote:
>> > On Thu, Apr 17, 2014 at 02:52:41PM +0200, drago01 wrote:
>> >> On Thu, Apr 17, 2014 at 2:51 PM, Chuck Anderson <cra at wpi.edu> wrote:
>> >> > On Wed, Apr 16, 2014 at 11:23:15PM +0200, drago01 wrote:
>> >> >> On Wed, Apr 16, 2014 at 9:11 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>> >> >> > Greetings.
>> >> >> >
>> >> >> > We have new f19/f20 images with openssl updated, and they appear to be
>> >> >> > default/live already.
>> >> >> >
>> >> >> > Were we waiting for some testing runs on them before announcing?
>> >> >> > (Which we should have done before making them live, imho)
>> >> >> >
>> >> >> > Or did that already happen?
>> >> >> >
>> >> >> > Did we want to do a full test cycle on them?
>> >> >> > Or just openssl related actions?
>> >> >>
>> >> >> Huh?
>> >> >>
>> >> >> Since when do we do something like this? Sounds like an over reaction to me.
>> >> >> Installing (security) updates is the first thing you should do after
>> >> >> installing anyway and besides who decided this and when?
>> >> >> What are the criteria for doing updated images?
>> >> >
>> >> > Live images can't be updated...
>> >>
>> >> 1) They can
>> >> 2) Live images are not supposed be used for production ..
>> >
>> > 1) Sure if you have a persistent live image on a USB I suppose.  But
>> > with CD/DVD media, you cannot update and then reboot as is necessary
>> > to fix the issue.  You can manually restart all processes/services
>> > that were linked against the old openssl I suppose, but you would have
>> > to go through this dance after every single boot to remove this
>> > vulnerability.
>>
>> Which service do we install and run by default that uses OpenSSL and
>> is configured to use SSL on the live media?
>> -> Answer is none.
>>
>> > 2) Live images could be used to rescue/repair a production
>> > environment,
>>
>> See above.
>>
>> > or could be used as a client to access a production
>> > environment.  For example one could be using "curl" which is linked
>> > against the bad openssl.
>>
>> curl is a client.
>
> Clients ARE affected:

Sure you can read out memory from a client the same way by an evil
server but its is far less serve as the
the server case ... besides if you are downloading stuff from a
compromised server you will most likely have other
issues then a server trying to read out your download clients memory
(web browsers would be a worthwhile target but
they do not use openssl).

This is not the only security issue that exists ... it is very bad for
*servers* because an attacker can spam you with requests
until he gets what he wants.

> Does anaconda or yum use OpenSSL?  Because then "yum updates" and
> "liveinst" are potentially affected.
>
> Does libvirt/virt-manager/virt-viewer use OpenSSL?  Because I could
> certainly see a sysadmin using a Live image to run
> virt-manager/virt-viewer to connect over the network via SSL to a
> hypervisor.

Not using live media no.

> Do VNC/RDP clients use OpenSSL?  rdesktop is linked against an OpenSSL
> library.  It may be possible to exploit it.

Its not about being "possible to exploit" its a bout the servity of
the issue by your logic we should spin media for every security issue
...

>> > We shouldn't leave our users exposed if they
>> > decide to use a live image, especially since I don't think it is
>> > documented anywhere that "these images are unsuitable for use in a
>> > production environment".
>>
>> There are unsuitable by their very nature of being live images.
>
> Why are we shipping unsuitable software then?

We don't. Live media is useful for 1) installing the system 2)
previewing or showcasing the system. Not for use in production
(especially not as a server)