hack serveru ?

[Pavel Kankovsky]

On Wed, 4 Jun 2003, Rybarik, Michal wrote:

> > read(7, "grep\0fork\0", 2047)           = 10
> > 
> > Tak sem zacal chvilku panikarit, ale pak mi doslo ze to 
> > spoustim na serveru, ktery byl momentalne zatizeny a je tam 
> > hodne bezicich procesu a vystup strace je dost dlouhy, takze 
> > ve vypise ps se objevi i ten grep s parametrem fork. Coz je
> > IMHO v poradku.
> 
> skusal som to na viacerych strojoch, rh 7.3 a 8.0 s 2.4 kernelom vypisali 
> ten grep fork, rh 6.2 s 2.2 kernelom nevypisal uplne nic.

To, zda to neco vypise, zalezi na okolnostech.

Vynechme z toho pro jednoduchost strace a predpokladejme, ze prvni prikaz
je jen ps.

Shell, ze ktereho je ten prikaz spousten, vyrobi dva potomky spojene
rourou (nebo lepe receno jednoho potomka a ten vytvori rouru a jeste
jednoho vlastniho potomka).

Prvni potomek, ten ktery ma zapisovaci konec roury, provede execve na ps,
druhy potomek, ten ktery ma cteci konec roury, provede execve na grep.
Pote tam chvilku chodi data, az ps skonci, uzavre rouru. Pak skonci i
grep. Takze to, ze grep neskonci driv nez ps, je zaruceno, nicmene naopak
to neplati, protoze muze dojit k tomu, ze ps je spusteno, provede vsechno,
co ma provest, a zapise to do bufferu (at uz vlastnich (stdio) nebo
jadernych) drive, nez vubec druhy potomek udela execve, cili pak v jeho
vystupu grep chybi. Nebo se naopak grep nastartuje rychle, a pak je ve
vystupu z ps videt.

Podobne to muze fungovat i v pripade, ze je do toho zamotany strace,
nicmene je tezsi vyvolat situaci, kdy tam grep chybi, protoze je start ps
zdlouhavejsi, jeho beh pomalejsi (kvuli strace) a navic generuje mnohem
vetsi objem dat, takze se drive zastavi na tom, ze ma plne buffery a ze
musi cekat, nez nekdo (grep) zacne z roury cist.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."