Strasidelny log na firewallu

[Pavel Kankovsky]

On Tue, 28 Sep 2004, Vlada Macek wrote:

> dnes jsem nasel v poste zpravu od logchecku na firewallu (486DX2, Debian
> Woody), ze nasel cosi nezvykleho v logu. Iptables mi loguji pod levelem
> debug a vsechny kern.=debug zpravy mam presmerovane do specialniho
> souboru kernel.firewall, ktery logcheck ignoruje. Nasledujici zprava ale
> nachazi uprostred dlouhe rady ---MARK--- v messages!
> 
> Sep 28 11:05:30 gate kernel: C=X.X.X.X DST=81.0.233.82 LEN=48 TOS=0x00
> PREC=0x00 TTL=127 ID=52471 DF PROTO=TCP SPT
> =1072 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0

Rekl bych, ze asi nejverohodnejsi vysvetleni je toto:

Jadro uklada hlasky, co patri do logu (generovane printk()), do kruhoveho 
bufferu. Ten se muze zaplnit, cili zapisovaci ukazatel predbehne o cele
kolo cteci ukazatel. A je problem. Existujici implementace se zda, ze 
tento problem resi tak, ze prepise dosud neprectena data a umele popostrci 
cteci ukazatel za prepsane misto. Takze to pravdepodobne vzniklo tak,
ze se kruhovy buffer ucpal a precnivajici hlaska prepsala kus teto 
inkriminovane. V prepsanem kusu bylo zaroven inicialni <L>, kde L je 
cislice urcujici zavaznost hlaseni, cili klogd dostal hlasku, ktera
byla uriznuta, a navic ji na zacatku chybelo zminene <L>, takze si 
domyslel nejakou implicitni hodnotu a proto to skoncilo v messages a ne 
v kernel.firewall.

Napada mne, ze by jadro mohlo tuto skutecnost (preteceni bufferu) nejak 
indikovat. Take by mohlo nejak resit situaci, kdy od nabotovani posle
do logu vic nez ULONG_MAX-delta znaku (v praxi to asi tak moc nehrozi, 
protoze aby to nastalo po 1-rocnim uptimu, tak by se muselo denne 
logovat > 10 MiB, ale stejne...), protoze pak se promenne v printk.c
otoci kolem dokola a nektere testy na nerovnost se rozsypou.

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