Re: When are security updates effective?

[paddy]

On Mon, Sep 04, 2006 at 09:15:45AM +0300, Mikko Rapeli wrote:
> On Sat, Sep 02, 2006 at 10:37:04AM +0200, Rolf Kutz wrote:
> > * Quoting Mikko Rapeli ([EMAIL PROTECTED]):
> > > I think it is relevant: should the effectiveness actions in general 
> > > be based on the host where the update was applied through lsof, package 
> > > dependencies provided and digitally signed by Debian, some other 
> > > information
> > > provided and digitally signed by the Debian security team in an
> > > advisory or something else?
> 
> Or package installation scripts provided by the package maintainer.
> 
> > The problem here is that when the software has
> > been exploited already, installing the security
> > update doesn't fix the problem anymore.
> 
> Exploited to what extend? Without stack protection, address space
> randomization, selinux etc, it's very difficult to know wether a
> processes address space has been violated. And non-privileged processes
> don't have write access to binary files on the system without additional
> local root holes.
> 
> My point is: lsof may not be trustworthy on per host basis when making
> security updates effective. The time between security bug publication and
> applying the updates varies too much. If a Linux distro can do better
> than Windows and not require full reboot after every update, I'd like to
> see a confirmation of the steps required to make the update effective
> from a source I trust anyway.

So you could have some system of compartments, where if there was a breach
in a compartment you could sanitise the compartment?  To take a more 
concrete example, suppose it's an ordinary user running a web browser in
their ordinary account, and a vulnerability is found in that browser, and
running instances must be assumed exploited.  Sounds like you're saying 
that lsof, even if the binary itself can be assumed sound, relies on data
from the compartment which could be compromised and so it's output for
the use you suggest cannot be completely trusted.  Seems to me that there
are plenty of other problems getting to a compartment you can sanitise
effectively, like the possibility of an exploit to persist via
filesystem and hooks like cron or .profile, no ? but I like the idea.

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Mikko Rapeli]

On Sat, Sep 02, 2006 at 10:37:04AM +0200, Rolf Kutz wrote:
> * Quoting Mikko Rapeli ([EMAIL PROTECTED]):
> > I think it is relevant: should the effectiveness actions in general 
> > be based on the host where the update was applied through lsof, package 
> > dependencies provided and digitally signed by Debian, some other information
> > provided and digitally signed by the Debian security team in an
> > advisory or something else?

Or package installation scripts provided by the package maintainer.

> The problem here is that when the software has
> been exploited already, installing the security
> update doesn't fix the problem anymore.

Exploited to what extend? Without stack protection, address space
randomization, selinux etc, it's very difficult to know wether a
processes address space has been violated. And non-privileged processes
don't have write access to binary files on the system without additional
local root holes.

My point is: lsof may not be trustworthy on per host basis when making
security updates effective. The time between security bug publication and
applying the updates varies too much. If a Linux distro can do better
than Windows and not require full reboot after every update, I'd like to
see a confirmation of the steps required to make the update effective
from a source I trust anyway.

-Mikko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Rolf Kutz]

* Quoting Mikko Rapeli ([EMAIL PROTECTED]):

> On Fri, Sep 01, 2006 at 06:56:17PM -0400, Michael Stone wrote:
> > On Sat, Sep 02, 2006 at 12:28:17AM +0300, Mikko Rapeli wrote:
> > >- can a process running vulnerable code be exploited to not show the
> > > shared libraries and other non-shared libraries and files it had opened 
> > > for reading at some point?
> > 
> > Of course it can. And that's irrelevant to the question at 
> > hand--installing a security update at that point isn't going to help.
> 
> I think it is relevant: should the effectiveness actions in general 
> be based on the host where the update was applied through lsof, package 
> dependencies provided and digitally signed by Debian, some other information
> provided and digitally signed by the Debian security team in an
> advisory or something else?

The problem here is that when the software has
been exploited already, installing the security
update doesn't fix the problem anymore.

> When an admin takes the chance and trusts lsof, that's fine. If low
> privilege process starts spamming the world he'll propably notice. But if
> making these upgrades effective is ever automated, I wouldn't like to take
> that chance.

True, but in the example from above it's too late
for that.

- Rolf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Mikko Rapeli]

On Fri, Sep 01, 2006 at 06:56:17PM -0400, Michael Stone wrote:
> On Sat, Sep 02, 2006 at 12:28:17AM +0300, Mikko Rapeli wrote:
> >- can a process running vulnerable code be exploited to not show the
> > shared libraries and other non-shared libraries and files it had opened 
> > for reading at some point?
> 
> Of course it can. And that's irrelevant to the question at 
> hand--installing a security update at that point isn't going to help.

I think it is relevant: should the effectiveness actions in general 
be based on the host where the update was applied through lsof, package 
dependencies provided and digitally signed by Debian, some other information
provided and digitally signed by the Debian security team in an
advisory or something else?

When an admin takes the chance and trusts lsof, that's fine. If low
privilege process starts spamming the world he'll propably notice. But if
making these upgrades effective is ever automated, I wouldn't like to take
that chance.

-Mikko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Michael Stone]

On Sat, Sep 02, 2006 at 12:28:17AM +0300, Mikko Rapeli wrote:

- can a process running vulnerable code be exploited to not show the
 shared libraries and other non-shared libraries and files it had opened for 
 reading at some point?


Of course it can. And that's irrelevant to the question at 
hand--installing a security update at that point isn't going to help.


Mike Stone


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Mikko Rapeli]

On Thu, Aug 31, 2006 at 07:23:27PM -0300, Henrique de Moraes Holschuh wrote:
> Indeed. lsof +L1 is currently useless for detecting unlinked libraries. 
> 
> I've been using lsof | grep "path inode" to detect them for a while now.
> Still, I hope the older, saner lsof +L1 behaviour can be restored soon...

This got me thinking: 
- can the output of lsof be trusted when making security updates effective?
- can a process running vulnerable code be exploited to not show the
  shared libraries and other non-shared libraries and files it had opened for 
  reading at some point?
- do I assume, fingers crossed, that non of my processes have been tampered 
  with if I trust lsof and don't do a full reboot?

AFAIK, shared libraries are just memory mapped files which can be copied
and munmap'ed, and an attacker can keep on running his 0wned process on
my host and escape my update attempts. I think this applies to all other open
files like static and scripting language libraries, data and configuration 
files too, and even in trusted environments processes don't show all of these 
loaded 'libraries' via open files. Perhaps package based reverse
dependencies give a better idea on what to do after upgrades, but the
dep's should be tracked all the way to the executables which started the
currently running processes, I think.

Strange, but suddenly XP's forced reboot on IE and Acroreader updates starts 
to make sense...

-Mikko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Petter Reinholdtsen]

[Dann Frazier]
> Would this help?
>   http://lists.debian.org/debian-devel/2006/08/msg00629.html

Getting all packages requiring an reboot to call
/usr/share/update-notifier/notify-reboot-required or touch
/var/run/reboot-required would definitely be a step in the right
direction, and handle kernel upgrades quite well.  I like that part of
the proposal.

But for user applications, it would be enough to log out and in again,
and that should be handled too.  And it will get more complicated for
multiuser machines (like LTSP thin clients or multiseat
installations), where each logged in user need to log out.  So each
users session need to keep track of when he logged in and check if
some changes requiring a logout has happened since then.  Should not
be too hard, though.

Friendly,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Henrique de Moraes Holschuh]

On Thu, 31 Aug 2006, Sam Morris wrote:
> > You can check with 
> > 
> > # lsof +L1
> > 
> > It will show you open Files that have been
> > unlinked. If any of those are part of the upgraded
> > packages, you restart that process.
> 
> Note that this has been broken since at most Linux 2.6.8. Relying on it
> may cause you to not notice that some processes need to be restarted after
> upgrading a package containing a shared library.
> 
> 

Indeed. lsof +L1 is currently useless for detecting unlinked libraries. 

I've been using lsof | grep "path inode" to detect them for a while now.
Still, I hope the older, saner lsof +L1 behaviour can be restored soon...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Sam Morris]

On Thu, 31 Aug 2006 09:55:26 +0200, Rolf Kutz wrote:

> * Quoting Mikko Rapeli ([EMAIL PROTECTED]):
> 
>> On Tue, Aug 29, 2006 at 10:54:45PM +0200, Moritz Muehlenhoff wrote:
>> > Mikko Rapeli wrote:
>> > > Could Debian security advisories help a bit, since the people making the
>> > > packaging changes propably know how to make the changes effective on a
>> > > running installation too?
>> > 
>> > If there's anything special to do (e.g. kernel or glibc) we alredy add this
>> > to the DSA text.
>> 
>> Yes, that's great, but some of the non-special cases are not that
>> obvious. Should I reboot or at least restart kdm after libtiff4 update?
>> 
>> On one host I get the feeling I don't since 'lsof 2>/dev/null | grep libtiff'
>> returns nothing. Then again this would suggest, that at least kde/kdm
>> needs to be restarted:
>> 
>> # apt-cache rdepends libtiff4|grep kde
>>   kdelibs4
>>   kdegraphics-kfile-plugins
>> 
>> So which one is it?
> 
> You can check with 
> 
> # lsof +L1
> 
> It will show you open Files that have been
> unlinked. If any of those are part of the upgraded
> packages, you restart that process.
> 
> - Rolf

Note that this has been broken since at most Linux 2.6.8. Relying on it
may cause you to not notice that some processes need to be restarted after
upgrading a package containing a shared library.



I currently rely on both lsof and the psdel script I wrote, link to from
that bug report.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?r

[Giacomo Mulas]

On Thu, 31 Aug 2006, Hans wrote:


It's a good idea but it will not catch all cases, some apps run for days
without any user interventions, nothing garanties that the pop up will
be seen, sending an email if the popup is not didmissed after a delay
could mitigate this.


I agree it will not catch all cases, but it will catch a good deal more than
the current situation. Sending an email may help catch some more cases, but
then a process may belong to a noninteracting user who never receives/reads
email. Maybe we can also have another timer which will actually send a
SIGTERM to still running processes which need to be restarted, after the
email also went unnoticed. But then, there might be cases in which you do
know what you are doing and really don't want to interrupt the running
process (say a very long scientific calculation on a completely isolated,
dedicated computer, where security is not a problem). There is no "one size
fits all" solution.

Bye
Giacomo

--
_

Giacomo Mulas <[EMAIL PROTECTED]>
_

OSSERVATORIO ASTRONOMICO DI CAGLIARI
Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)

Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222
Tel. (UNICA): +39 070 675 4916
_

"When the storms are raging around you, stay right where you are"
 (Freddy Mercury)
_

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Hans]

Le jeudi 31 août 2006 à 10:08 +0200, Giacomo Mulas a écrit :
> On Wed, 30 Aug 2006, Noah Meyerhans wrote:
> 
> > workstations for which I'm responsible, and it's difficult for me to
> > make sure that the users e.g. restart firefox when we release an update.
> 
> It would be nice to agree to a convention whereas when an app gets some
> well-defined signal it ought to tell the user it needs to be restarted as
> soon as possible. 

I should not have to be the app that does the notification. This way
application need no modifications for this this work.

> Then we could add some simple logic to the postinst
> scripts for security updates using, e.g., lsof to find which processes are
> using the replaced library and send signals to them.

with this he know who is running which apps that use the old libs, no
need to notify the apps, notify the user.

"chkrestart" will tell you which old files, libraries are opened by
running processes. 

>  Ok, it's not something
> in the short term but it would be sensible in the long run. 

If it does not need any modification for the apps then it can be
implemeted faster.

> And it could
> actually work. Otherwise, another (sort of) solution would be to have the
> script identify the user that is running the process to be restarted and use
> a standardised solution to tell him/her the app ought to be restarted (e.g.
> wall on a terminal, a popup if he/she is running it on a graphical
> environment). Whaddya think?

It's a good idea but it will not catch all cases, some apps run for days
without any user interventions, nothing garanties that the pop up will
be seen, sending an email if the popup is not didmissed after a delay
could mitigate this.

Hans.

> 
> Bye
> Giacomo
> 
> -- 
> _
> 
> Giacomo Mulas <[EMAIL PROTECTED]>
> _
> 
> OSSERVATORIO ASTRONOMICO DI CAGLIARI
> Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)
> 
> Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222
> Tel. (UNICA): +39 070 675 4916
> _
> 
> "When the storms are raging around you, stay right where you are"
>   (Freddy Mercury)
> _
> 
> -- 
> Il messaggio e' stato analizzato alla ricerca di virus o
> contenuti pericolosi da MailScanner, ed e'
> risultato non infetto.
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Giacomo Mulas]

On Wed, 30 Aug 2006, Noah Meyerhans wrote:


workstations for which I'm responsible, and it's difficult for me to
make sure that the users e.g. restart firefox when we release an update.


It would be nice to agree to a convention whereas when an app gets some
well-defined signal it ought to tell the user it needs to be restarted as
soon as possible. Then we could add some simple logic to the postinst
scripts for security updates using, e.g., lsof to find which processes are
using the replaced library and send signals to them. Ok, it's not something
in the short term but it would be sensible in the long run. And it could
actually work. Otherwise, another (sort of) solution would be to have the
script identify the user that is running the process to be restarted and use
a standardised solution to tell him/her the app ought to be restarted (e.g.
wall on a terminal, a popup if he/she is running it on a graphical
environment). Whaddya think?

Bye
Giacomo

--
_

Giacomo Mulas <[EMAIL PROTECTED]>
_

OSSERVATORIO ASTRONOMICO DI CAGLIARI
Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)

Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222
Tel. (UNICA): +39 070 675 4916
_

"When the storms are raging around you, stay right where you are"
 (Freddy Mercury)
_

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Rolf Kutz]

* Quoting Mikko Rapeli ([EMAIL PROTECTED]):

> On Tue, Aug 29, 2006 at 10:54:45PM +0200, Moritz Muehlenhoff wrote:
> > Mikko Rapeli wrote:
> > > Could Debian security advisories help a bit, since the people making the
> > > packaging changes propably know how to make the changes effective on a
> > > running installation too?
> > 
> > If there's anything special to do (e.g. kernel or glibc) we alredy add this
> > to the DSA text.
> 
> Yes, that's great, but some of the non-special cases are not that
> obvious. Should I reboot or at least restart kdm after libtiff4 update?
> 
> On one host I get the feeling I don't since 'lsof 2>/dev/null | grep libtiff'
> returns nothing. Then again this would suggest, that at least kde/kdm
> needs to be restarted:
> 
> # apt-cache rdepends libtiff4|grep kde
>   kdelibs4
>   kdegraphics-kfile-plugins
> 
> So which one is it?

You can check with 

# lsof +L1

It will show you open Files that have been
unlinked. If any of those are part of the upgraded
packages, you restart that process.

- Rolf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Mikko Rapeli]

On Tue, Aug 29, 2006 at 10:54:45PM +0200, Moritz Muehlenhoff wrote:
> Mikko Rapeli wrote:
> > Could Debian security advisories help a bit, since the people making the
> > packaging changes propably know how to make the changes effective on a
> > running installation too?
> 
> If there's anything special to do (e.g. kernel or glibc) we alredy add this
> to the DSA text.

Yes, that's great, but some of the non-special cases are not that
obvious. Should I reboot or at least restart kdm after libtiff4 update?

On one host I get the feeling I don't since 'lsof 2>/dev/null | grep libtiff'
returns nothing. Then again this would suggest, that at least kde/kdm
needs to be restarted:

# apt-cache rdepends libtiff4|grep kde
  kdelibs4
  kdegraphics-kfile-plugins

So which one is it?

update-notifier seems nice, but how does it know what to do? I looked at
the code but couldn't see how it knows when to reboot and when package
upgrade is enough.

-Mikko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[dann frazier]

On Wed, Aug 30, 2006 at 03:45:04PM -0400, Noah Meyerhans wrote:
> I haven't come up with a really good solution to this problem.  I
> actually sort of like the Windows method of incessantly nagging the user
> to reboot their machine (it literally pops up a dialog box every few
> minutes).  I like the idiot-proof factor.  Yes, they can ignore the
> popups, but they come so quickly that even the most stubborn user will
> get sick of them and reboot.  I'd hate it if I was a Windows user,
> though, I'm sure!

Would this help?
  http://lists.debian.org/debian-devel/2006/08/msg00629.html

-- 
dann frazier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Henri Salo]

Noah Meyerhans wrote:

On Tue, Aug 29, 2006 at 10:54:45PM +0200, Moritz Muehlenhoff wrote:
  

If there's anything special to do (e.g. kernel or glibc) we alredy add this
to the DSA text.



I don't think that's quite enough.  I have a few hundred Debian
workstations for which I'm responsible, and it's difficult for me to
make sure that the users e.g. restart firefox when we release an update.
Daemons automatically get restarted, but desktop apps require
intervention.  In my case, the desktop apps aren't being run by the
people installing the updates (the updates are typically installed
either remotely or fully automatically) and that makes things even more
difficult.

I haven't come up with a really good solution to this problem.  I
actually sort of like the Windows method of incessantly nagging the user
to reboot their machine (it literally pops up a dialog box every few
minutes).  I like the idiot-proof factor.  Yes, they can ignore the
popups, but they come so quickly that even the most stubborn user will
get sick of them and reboot.  I'd hate it if I was a Windows user,
though, I'm sure!

noah

  
Just write a script what closes all firefoxes after update. Haha that 
wouldn't be so disturbing.


--
Henri Salo | [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When are security updates effective?

[Noah Meyerhans]

On Tue, Aug 29, 2006 at 10:54:45PM +0200, Moritz Muehlenhoff wrote:
> If there's anything special to do (e.g. kernel or glibc) we alredy add this
> to the DSA text.

I don't think that's quite enough.  I have a few hundred Debian
workstations for which I'm responsible, and it's difficult for me to
make sure that the users e.g. restart firefox when we release an update.
Daemons automatically get restarted, but desktop apps require
intervention.  In my case, the desktop apps aren't being run by the
people installing the updates (the updates are typically installed
either remotely or fully automatically) and that makes things even more
difficult.

I haven't come up with a really good solution to this problem.  I
actually sort of like the Windows method of incessantly nagging the user
to reboot their machine (it literally pops up a dialog box every few
minutes).  I like the idiot-proof factor.  Yes, they can ignore the
popups, but they come so quickly that even the most stubborn user will
get sick of them and reboot.  I'd hate it if I was a Windows user,
though, I'm sure!

noah



signature.asc
Description: Digital signature

Re: When are security updates effective?

[Moritz Muehlenhoff]

Mikko Rapeli wrote:
> Could Debian security advisories help a bit, since the people making the
> packaging changes propably know how to make the changes effective on a
> running installation too?

If there's anything special to do (e.g. kernel or glibc) we alredy add this
to the DSA text.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]