Cotygodniowe dziury...

[Jakub Bogusz]

On Mon, Jun 24, 2002 at 11:11:12AM +0200, Blues wrote:
> Teraz BARDZO poważna rzecz. Ten overflow wydaje się, że działa, choć 
> raport jest o wcześniejszej wersji. Aktualnie nie ma fixa dostępnego... 
> Jak ktoś znajdzie/zrobi to niech się nie krępuje :)
> 
> Procmail
> 
>     Vendor: Procmail.org
> 
>     A heap overflow vulnerability was reported in 'procmail'.  A
>     local user may be able to gain root privileges on the system, but
>     that has not been verified.
> 
>     Impact: Execution of arbitrary code via local system
> 
>     Alert: http://securitytracker.com/alerts/2002/Jun/1004584.html

Nie dotyczy zwykłej instalacji:

-rwxr-xr-x    1 root     root        68572 lis  8  2001 /usr/bin/procmail

Nie wiem czy w ogóle overflow działa[1], ale i tak jest błąd do poprawki -
u mnie z długim command line zachowuje się tak samo jak bez, tzn. czeka
na input, po ^C pisze:

procmail: Terminating prematurely
Segmentation fault

Pod ^D w obu przypadkach zachowuje się OK.

[1] raczej nie, bo na podanym przykładzie po ^D pisze:

procmail: Assignment to variable with excessively long name skipped

> Mozilla Browser
> 
>     Vendor: Mozilla.org
> 
>     A vulnerability was reported in the e-mail component of
>     Mozilla. A remote user could send a specially crafted e-mail
>     message that will cause the Mozilla e-mail client to fail to
>     download messages when downloading the message from a POP3 server.
> 
>     Impact: Denial of service via network
> 
>     Alert: http://securitytracker.com/alerts/2002/Jun/1004572.html

A co ze zdalnym wyłączaniem XFS lub X-serwera przez duże fonty w CSS?

Workaround powinien być w CVS mozilli.
Co do samych XFree86 to nie wiem, bo Juliusz Chroboczek na bugtraq
napisał:

| I see.  Two bugs here.
| 
| One is the dodgy error-handling in the Type 1 backend, which gives up
| by calling abort() (see the very end of curves.c).  I agree that this
| is a bug; however, as I'm hoping to phase out the current Type 1
| backend in favour of one based on FreeType 2 in time for 4.3.0, I do
| not intend to fix it.
| 
| The other problem is that we do not fail a priori requests for very
| large fonts.  I do agree that this should be done, and I think it
| should be done at the common layer (above the font backends); could
| anyone suggest at what point a request for a font is clearly invalid?


-- 
Jakub Bogusz