[ Ramirez @ 31.01.2005. 10:31 ] @
[ Ramirez @ 31.01.2005. 10:31 ] @
[ Reljam @ 31.01.2005. 16:34 ] @
To nije rupa (sigurno ne u onom smislu u kojem su bile rupe ono sto se desavalo prosle godine): heap protection nije mera zastite koja sluzi da zastiti kompjuter od upada u normalnom radu. Prilikom aktivacije heap protectiona, proces u kome se to desilo namerno biva unisten - znaci to nije nesto sto se koristi u svakodnevnom radu. Heap protection sluzi kao zadnji red odbrane, znaci kada je nesto vec uspelo da se provuce kroz standardne metode zastite i kada sistem reaguje tako sto nasilno ubije program u kome se to desilo.
[ Sundance @ 31.01.2005. 17:41 ] @
DEP još nije doživio svoj konačan napredak, ovi minorni defekti u izvedbi će vjerojatno ubrzo biti ispravljeni. Algoritamski su rješivi većina problema sa preljevima (integer, heap, buffer) i samo je pitanje vremena kad će win32api duboko dole dovoljno "očvrsnuti" da ovakvi problemi budu prošlost (well, uglavnom :)
A tu je dakako i managed kod (.NET, winFX, standard na Longhornu), koji će istrijebiti ovakve bugove k'o zeca! malloc() koriste samo pussiez..živio moj predragi GC! :) [Shadowed: Obrisan flame deo.] [ Ramirez @ 02.02.2005. 09:16 ] @
[ Sundance @ 02.02.2005. 14:41 ] @
Citat: "In this situation, we decided it would be much safer for the industry to be aware of the new, existing threat," Maksimov wrote in an e-mail. "Such a vulnerability cannot cause a new worm or virus (to appear). But that's exactly the situation when it is much better to know about the problem, than not." Citat: "Maybe you could classify this problem as a lost opportunity on Microsoft's part to protect Windows better, but that doesn't make it a vulnerability Lindstrom said. I jedni i drugi vele da se ne radi ni o kakvoj "rupi". EOD. Copyright (C) 2001-2025 by www.elitesecurity.org. All rights reserved.
|