|
|
 | "Du skal bare installere en firewall"
Fra : Andreas Plesner Jaco~ |
Dato : 13-05-04 21:13 |
|
Skarpt i hælene på visse personers ide om at en firewall altid er
løsningen har Eeye fundet ikke mindre end 4 fejl i Symantec firewalls -
hvoraf 3 (TRE!) giver mulighed for at udføre kode på den angrebne
maskine, en angrebsvektor, der ikke var til stede før installation af
firewallen.
Det er så vidt jeg ved nu anden gang inden for meget kort tid, hvor
software-firewalls rent faktisk har øget risikoen for angreb betydeligt.
--
Andreas Plesner Jacobsen | I wouldn't marry her with a ten foot pole.
| |
 Michael Legart (13-05-2004)
| Kommentar
Fra : Michael Legart |
Dato : 13-05-04 21:14 |
|
On 2004-05-13, Andreas Plesner Jacobsen <apj@daarligstil.dk> wrote:
>
> Det er så vidt jeg ved nu anden gang inden for meget kort tid, hvor
> software-firewalls rent faktisk har øget risikoen for angreb betydeligt.
Man skal bare installere Linux.
--
hestdesign.info - we put the hest in .com
| |
Alex Holst (13-05-2004)
| Kommentar
Fra : Alex Holst |
Dato : 13-05-04 21:23 |
|
Michael Legart wrote:
> On 2004-05-13, Andreas Plesner Jacobsen <apj@daarligstil.dk> wrote:
>
>>Det er så vidt jeg ved nu anden gang inden for meget kort tid, hvor
>>software-firewalls rent faktisk har øget risikoen for angreb betydeligt.
>
> Man skal bare installere Linux.
Hvad vil du helst: skydes eller skylde oel? *Mange* oel.
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
| |
Troels Arvin (13-05-2004)
| Kommentar
Fra : Troels Arvin |
Dato : 13-05-04 21:19 |
|
On Thu, 13 May 2004 20:12:45 +0000, Andreas Plesner Jacobsen wrote:
> Skarpt i hælene på visse personers ide om at en firewall altid er
> løsningen har Eeye fundet ikke mindre end 4 fejl i Symantec firewalls -
> hvoraf 3 (TRE!) giver mulighed for at udføre kode på den angrebne
> maskine
Fantastisk. Har du i øvrigt en reference?
--
Greetings from Troels Arvin, Copenhagen, Denmark
| |
Andreas Plesner Jaco~ (13-05-2004)
| Kommentar
Fra : Andreas Plesner Jaco~ |
Dato : 13-05-04 21:23 |
| | |
 Peter Brodersen (13-05-2004)
| Kommentar
Fra : Peter Brodersen |
Dato : 13-05-04 21:38 |
| | |
Michael Legart (13-05-2004)
| Kommentar
Fra : Michael Legart |
Dato : 13-05-04 23:12 |
| | |
Asbjorn Hojmark (13-05-2004)
| Kommentar
Fra : Asbjorn Hojmark |
Dato : 13-05-04 23:31 |
|
On Thu, 13 May 2004 22:12:07 +0000 (UTC), Michael Legart
<michaelnospam@hest.nu> wrote:
> Se, den slags var aldrig sket, hvis det havde vaeret open source!
Nej, nu stopper du. I hvert fald her.
<<plonk>>
-A
--
http://www.hojmark.org/
| |
Christian E. Lysel (15-05-2004)
| Kommentar
Fra : Christian E. Lysel |
Dato : 15-05-04 22:36 |
|
In article <slrnca7sln.ohn.michaelnospam@kamel.legart.dk>, Michael Legart wrote:
> Se, den slags var aldrig sket, hvis det havde vaeret open source!
Symantec har haft den ene fejl tidligere i deres SEF.
--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/
| |
Kasper Dupont (14-05-2004)
| Kommentar
Fra : Kasper Dupont |
Dato : 14-05-04 06:12 |
| | |
Alex Holst (14-05-2004)
| Kommentar
Fra : Alex Holst |
Dato : 14-05-04 13:42 |
| | |
Alex Holst (13-05-2004)
| Kommentar
Fra : Alex Holst |
Dato : 13-05-04 21:24 |
| | |
Michael U. Hove (14-05-2004)
| Kommentar
Fra : Michael U. Hove |
Dato : 14-05-04 01:05 |
|
Alex Holst wrote:
> Troels Arvin wrote:
>
>> Fantastisk. Har du i øvrigt en reference?
>
>
> Det er saa smukt.
>
> http://www.eeye.com/html/Research/Advisories/index.html
>
Nu er jeg ikke selv *master C/C++-koder* til daglig (men sysadm, så jeg
har eftervirkningerne inde på livet!), men jeg kan da stave mig igennem
et "Hello world"-prog, og lidt til.
Der er noget der har undret mig længe...
Hvorfor er owerflows (heap, integer, stack, whatever) så ekstremt
udbredte blandt exploits?!
Det synes som om alle sårbarheder udnytter en ell. anden form for mangel
på inputvalidering og hukommelses allokering (hvis jeg altså har
forstået principperne bag korrekt?!) hvad enten det er apps. ell.
kernel-level bugs.
Ved at der findes metoder til at hjælpe på de værste problemer (OpenBSDs
non-eksekverbare stack osv., Stackguard, libsafe, Boehm collectors osv.)
Men hvis man antager (som nogen har gjort):
http://www.research.att.com/projects/cyclone/
- at det er C/C++'s skyld!, er det så fordi at sproget *er* for "svært"
at kode sikkert, ell. er det "the modern day" programmør der ikke har
*tid* til at skabe sikker kode pga. økonomisk pres, deadlines,
uretfærdige chefer etc. etc.
Man skulle mene, at vores allesammens hverdag ville blive ca 500%
nemmere, hvis der svømmede mindre sårbar kode rundt (dah....), men er
det helt urealistisk, at forvente, at exploit antallet vil gå andet end
opad?!
Skal man gå væk fra C/C++ (til hvad aner jeg ikke...) til at kode OS +
apps. i fremtiden,
Findes der simpelthen ingen "genvej" til mere sikker kode, andet end
minituøs source review linie for linie?!
Og er dette overhovedet foreneligt med en kommerciel
udviklingsmodel...noget tyder nemlig umiddelbart for mig på det modsatte.
Mvh.
Michael.
--
A typical day in the life of a UNIX user:
"unzip,touch, finger, strip, mount, yes, core dump, umount, sleep"
Mark Taylor.
| |
Kasper Dupont (14-05-2004)
| Kommentar
Fra : Kasper Dupont |
Dato : 14-05-04 06:10 |
|
"Michael U. Hove" wrote:
>
>
> Skal man gå væk fra C/C++ (til hvad aner jeg ikke...) til at kode OS +
> apps. i fremtiden,
Det er ikke nødvendigt at gå væk fra C, hvis man synes
godt om sproget. Man kunne godt indbygge runtime check i C,
som man har det i mange andre sprog. Men runtime check
koster.
Du får aldrig et krav om runtime check ind i C standarden.
Men derfor kan en C compiler sagtens generere kode med
runtime check. Den vil stadig overholde standarden hvis
den giver en runtime error i tilfælde hvor kode i forhold
til standarden har udefineret opførsel.
>
> Findes der simpelthen ingen "genvej" til mere sikker kode, andet end
> minituøs source review linie for linie?!
Der findes mange "genveje". I hvert fald hvis man blot
tænker på mindre tid brugt på at kode. Men ikke hvis man
også tænker performance.
Både runtime check og statisk analyse af programmer. Jeg
må dog indrømme, at jeg kender ikke nogen konkrete
produkter til at foretage det.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Jacob Sparre Anderse~ (15-05-2004)
| Kommentar
Fra : Jacob Sparre Anderse~ |
Dato : 15-05-04 15:47 |
|
Kasper Dupont skrev:
> Michael U. Hove skrev:
> > Skal man gå væk fra C/C++ (til hvad aner jeg ikke...) til at kode
> > OS + apps. i fremtiden,
C som det ser ud i dag kræver i hvert fald meget stor omhu fra
programmørernes side, hvis de ikke skal lave fejl af den type.
> Det er ikke nødvendigt at gå væk fra C, hvis man synes godt om
> sproget. Man kunne godt indbygge runtime check i C, som man har det
> i mange andre sprog.
Ville det ikke være en ret voldsom ændring af C? Mig bekendt kan man
selv i C99 ikke angive specifikke intervaller for taltyper.
> Men runtime check koster.
Ja. Fidusen er at få lavet så mange af tjekkene som muligt allerede
ved oversættelsen. SPARK [1] ser i den forbindelse ekstremt
interessant ud (jeg har ikke selv prøvet det endnu).
> Du får aldrig et krav om runtime check ind i C standarden. Men
> derfor kan en C compiler sagtens generere kode med runtime
> check. Den vil stadig overholde standarden hvis den giver en runtime
> error i tilfælde hvor kode i forhold til standarden har udefineret
> opførsel.
Ja. Men vil det ikke kræve at man indsætter køretidstjek overalt.
Eller er det realistisk at lade oversætteren lave en statisk analyse
af hvor de er nødvendige (som en Ada-oversætter vist typisk gør).
> > Findes der simpelthen ingen "genvej" til mere sikker kode, andet
> > end minituøs source review linie for linie?!
>
> Der findes mange "genveje". I hvert fald hvis man blot tænker på
> mindre tid brugt på at kode. Men ikke hvis man også tænker
> performance.
Det er jeg ikke helt overbevist om. SPARK laver for eksempel en
komplet statisk analyse af om der kan opstå overløb allerede i
forbindelse med oversættelsen af programmet. (problemet for mange
programmører er så at SPARK ikke er C, men Ada)
> Både runtime check og statisk analyse af programmer. Jeg må dog
> indrømme, at jeg kender ikke nogen konkrete produkter til at
> foretage det.
Jeg har vist allerede reklameret nok for S.... 
Og nej, jeg har ikke aktier eller andre økonomiske interesse i Praxis.
Jacob
[1] < http://www.praxis-cs.co.uk/sparkada/>
--
"A terrorist is someone who has a bomb but doesn't have an
air force." -- not from DoD Directive 2000.12
| |
Kasper Dupont (15-05-2004)
| Kommentar
Fra : Kasper Dupont |
Dato : 15-05-04 17:10 |
|
Jacob Sparre Andersen wrote:
>
> Kasper Dupont skrev:
>
> > Det er ikke nødvendigt at gå væk fra C, hvis man synes godt om
> > sproget. Man kunne godt indbygge runtime check i C, som man har det
> > i mange andre sprog.
>
> Ville det ikke være en ret voldsom ændring af C?
Jeg mener ikke det kræver nogen ændring af sproget. Blot en
ændring af compileren. Det vil ikke blive binært kompatibelt,
så man skal lige skrive noget interface kode mod kernen, og
recompilere sine libraries.
En pointer kunne f.eks. laves omtrent som følgende struktur:
struct pointer{
type_t *base,*limit,*ptr;
uint64_t serial;
uint32_t idx;
};
Og et runtime check af en pointer ville så være noget i
retning af:
((p->ptr >= p->base)&&(p->ptr+1 <= p->limit)&&(p->idx<nserials)&&(serials[p->idx]==p->serial))
Hvilket selvfølgelig ikke skal skrives i C koden, men derimod
skal genereres af compileren. Pointer aritmetik vil så bare
være at opdatere ptr feltet og kopiere resten af felterne fra
den oprindelige pointer.
Casts mellem integers og pointere ville nok blive et problem,
men det er de vel allerede i dag. Kræver C standarden, at man
kan få noget fornuftigt ud af at caste mellem pointere og
integers? Jeg ville nok foreslå at et cast af en pointer til
en integer gav ptr feltet, og et cast af en integer til en
pointer altid gav NULL eller en anden pointer, der aldrig
ville slippe gennem runtime checket.
En NULL pointer skulle så have base==limit, hvilket aldrig
ville blive accepteret af runtime checket.
> Mig bekendt kan man
> selv i C99 ikke angive specifikke intervaller for taltyper.
Det behøver man vel heller ikke for at lave runtime checks
af alle pointere. C standarden forbyder jo ikke runtime
checks af pointere. C standarden siger i mange tilfælde at
noget har et udefineret resultat. En runtime error er en
gyldig implementation af udefineret resultat.
>
> > Men runtime check koster.
>
> Ja. Fidusen er at få lavet så mange af tjekkene som muligt allerede
> ved oversættelsen.
Enig.
> SPARK [1] ser i den forbindelse ekstremt
> interessant ud (jeg har ikke selv prøvet det endnu).
Kender det ikke.
>
> (problemet for mange
> programmører er så at SPARK ikke er C, men Ada)
Jeg ville nok være villig til at lære et nyt sprog, hvis
jeg kunne se nogle fordele ved det. Men er der nogen
sprog udover C og C++ hvor jeg har mulighed for at udnytte
alle features i den API kernen stiller til rådighed?
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Jacob Sparre Anderse~ (15-05-2004)
| Kommentar
Fra : Jacob Sparre Anderse~ |
Dato : 15-05-04 17:38 |
|
Kasper Dupont skrev:
> Jacob Sparre Andersen wrote:
> > Ville det ikke være en ret voldsom ændring af C?
>
> Jeg mener ikke det kræver nogen ændring af sproget. Blot en
> ændring af compileren.
O.k. Men så er jeg ret sikker på at man vil få et halvstort
køretidsoverhead. Det er på den anden side nok alligevel ændringen
værd.
> > Mig bekendt kan man selv i C99 ikke angive specifikke intervaller
> > for taltyper.
>
> Det behøver man vel heller ikke for at lave runtime checks af alle
> pointere.
Nej, men det hjælper oversætteren med at finde ud af hvor køretidstjek
er nødvendige og hvor de kan udelades.
> > (problemet for mange programmører er så at SPARK ikke er C, men
> > Ada)
>
> Jeg ville nok være villig til at lære et nyt sprog, hvis jeg kunne
> se nogle fordele ved det. Men er der nogen sprog udover C og C++
> hvor jeg har mulighed for at udnytte alle features i den API kernen
> stiller til rådighed?
Ada har det i det mindste. Det eneste irritationsmoment er at man
skal importere funktionerne en ad gangen. Det er selvfølgelig en
overskuelig opgave, hvis man har et program der generer
import-specifikationerne. Sådanne programmer findes, men jeg plejer
at gøre det i hånden eller bruge import-specifikationer jeg får fra
andre (men nu er det også sjældent jeg selv importerer mere end en
enkelt funktion "glibc" til et program).
Jacob
--
»Saving keystrokes is the job of the text editor, not the
programming language.« -- Preben Randhol
| |
Kasper Dupont (15-05-2004)
| Kommentar
Fra : Kasper Dupont |
Dato : 15-05-04 18:43 |
|
Jacob Sparre Andersen wrote:
>
> Kasper Dupont skrev:
> > Jacob Sparre Andersen wrote:
>
> > > Ville det ikke være en ret voldsom ændring af C?
> >
> > Jeg mener ikke det kræver nogen ændring af sproget. Blot en
> > ændring af compileren.
>
> O.k. Men så er jeg ret sikker på at man vil få et halvstort
> køretidsoverhead.
Det er jeg fuldstændig enig i. Selvfølgelig skal optimizeren
køres både før og efter runtime checkene indsættes, men der
vil stadig være et væsentligt overhead tilbage.
> Det er på den anden side nok alligevel ændringen værd.
I mange situationer vil det være. Personligt ville jeg bruge
det til debuging og til servere, der ikke har ret meget
arbejde at lave i forhold til deres tilgængelige CPU resourcer.
>
> > > Mig bekendt kan man selv i C99 ikke angive specifikke intervaller
> > > for taltyper.
> >
> > Det behøver man vel heller ikke for at lave runtime checks af alle
> > pointere.
>
> Nej, men det hjælper oversætteren med at finde ud af hvor køretidstjek
> er nødvendige og hvor de kan udelades.
Ja, det har du ret i. Men på den anden side kræver det vel
så flere køretidstjek for at holde øje med, om intervallet
overholdes. Så jeg kan ikke lige gennemskue, om det i
sidste ende giver bedre eller dårligere performance.
>
> Ada har det i det mindste. Det eneste irritationsmoment er at man
> skal importere funktionerne en ad gangen. Det er selvfølgelig en
> overskuelig opgave, hvis man har et program der generer
> import-specifikationerne. Sådanne programmer findes, men jeg plejer
> at gøre det i hånden eller bruge import-specifikationer jeg får fra
> andre (men nu er det også sjældent jeg selv importerer mere end en
> enkelt funktion "glibc" til et program).
Det kunne være jeg skulle se om sproget var noget for mig.
Jeg kiggede lidt på nettet efter oplysninger om sproget,
og jeg fandt den her side:
http://www.linuxbog.dk/program/program/vaelg-et-sprog.html
Er der andre gode sider at læse.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Jacob Sparre Anderse~ (16-05-2004)
| Kommentar
Fra : Jacob Sparre Anderse~ |
Dato : 16-05-04 08:14 |
|
Kasper Dupont skrev:
> Det kunne være jeg skulle se om sproget var noget for mig. Jeg
> kiggede lidt på nettet efter oplysninger om sproget, og jeg fandt
> den her side:
>
> http://www.linuxbog.dk/program/program/vaelg-et-sprog.html
>
> Er der andre gode sider at læse.
Jeg vil foreslå at du bruger < http://www.adapower.com/learn/> som
udgangspunkt. Jeg har svært ved at sige hvilke af henvisningerne der
der er bedst til at overskue sproget, men »Ada Distilled« er i det
mindste en ret kompakt gennemgang.
Hvis du finder ud af at det er interessant, så kan du finde
referencemanualen (ISO-standarden) på
< http://www.adaic.com/standards/ada95.html>.
Jacob
--
"The same equations have the same solutions."
| |
Stig Johansen (14-05-2004)
| Kommentar
Fra : Stig Johansen |
Dato : 14-05-04 06:37 |
|
Michael U. Hove wrote:
> Der er noget der har undret mig længe...
>
> Hvorfor er owerflows (heap, integer, stack, whatever) så ekstremt
> udbredte blandt exploits?!
Jeg går ud fra, du mener udbredte bug's, der kan exploites?
> Det synes som om alle sårbarheder udnytter en ell. anden form for mangel
> på inputvalidering og hukommelses allokering (hvis jeg altså har
> forstået principperne bag korrekt?!) hvad enten det er apps. ell.
> kernel-level bugs.
Det har du forstået korrekt. Et typisk eksempel kunne være, at man allokerer
100 bytes, men tillader[1], at der modtages flere end 100 bytes, hvilket
skaber et problem.
[1] Eller mangler at kontrollere størrelsen af input.
>
> Ved at der findes metoder til at hjælpe på de værste problemer (OpenBSDs
> non-eksekverbare stack osv., Stackguard, libsafe, Boehm collectors osv.)
Ja, og en ordentlig compiler burde have range/stack checking indbygget.
>
> Men hvis man antager (som nogen har gjort):
>
> http://www.research.att.com/projects/cyclone/
>
> - at det er C/C++'s skyld!, er det så fordi at sproget *er* for "svært"
> at kode sikkert, ell. er det "the modern day" programmør der ikke har
> *tid* til at skabe sikker kode pga. økonomisk pres, deadlines,
> uretfærdige chefer etc. etc.
Det har helt klart noget med penge(tid) at gøre, altså først på markedet.
Hvis vi tager Microsoft som eksempel, så er jeg helt sikker på, de kunne
levere nogle meget bedre produkter, hvis de havde 'mere tid'.
Men der er også 2 andre aspekter, jeg har mødt gennem tiden:
1) Det vi kalder kodeskræk. Det er den type mennesker, der bruger korte
variabelnavne, samt ikke 'gider' at checke på statuskoder.
2) Den type mennesker, der mener et program er færdigt, når det for første
gang viser et resultat(=for dårlig test).
>
> Man skulle mene, at vores allesammens hverdag ville blive ca 500%
> nemmere, hvis der svømmede mindre sårbar kode rundt (dah....), men er
> det helt urealistisk, at forvente, at exploit antallet vil gå andet end
> opad?!
Hvis man, som du siger, lavede programmer med henblik på stabilitet og
vedligeholdelse, ville vores hverdag blive åhh så dejlig. Problemstillingen
er her, at de fleste laver programmerne 'hurtigst mulig' og ikke 'bedst
muligt' hvor:
'hurtigst mulig' = billigst at producere, dyrest at vedligeholde.
'bedst muligt' = dyrest at producere, men billigst at vedligeholde.
> Skal man gå væk fra C/C++ (til hvad aner jeg ikke...) til at kode OS +
> apps. i fremtiden,
Det løser nok ikke de fundamentale disciplinære problemer.
> Findes der simpelthen ingen "genvej" til mere sikker kode, andet end
> minituøs source review linie for linie?!
Jo - disciplin under programmeringen.
> Og er dette overhovedet foreneligt med en kommerciel
> udviklingsmodel...noget tyder nemlig umiddelbart for mig på det modsatte.
Vi er inde i den problemstilling, jeg plejer at kalde 'burhønse effekten'.
Forbrugerne vil simpelhen have den billigste løsning frem for den bedste
løsning.
Bemærk her, at jeg hentyder til anskaffele, og ikke til TCO/ROI.
--
Med venlig hilsen
Stig Johansen
| |
Klaus Ellegaard (14-05-2004)
| Kommentar
Fra : Klaus Ellegaard |
Dato : 14-05-04 07:18 |
|
"Michael U. Hove" <pots_72@e-mail.dk> writes:
>- at det er C/C++'s skyld!, er det så fordi at sproget *er* for "svært"
>at kode sikkert, ell. er det "the modern day" programmør der ikke har
>*tid* til at skabe sikker kode pga. økonomisk pres, deadlines,
>uretfærdige chefer etc. etc.
Nu er det jo meget få kommercielle projekter, der skrives i C/C++
i dag. Det meste forretningslogik skrives i J2EE, ABAP eller noget
tilsvarende. Men det er bare ikke så heldigt at skrive OS-nære
værktøjer i det, så grundlaget for det hele er stadig C/C++.
Det er ikke særlig svært at skrive sikker kode, men det tager tid.
Ikke blot i C/C++ - se bare den aktuelle diskussion om PHP og folks
manglende evner til inputvalidering dér.
>Findes der simpelthen ingen "genvej" til mere sikker kode, andet end
>minituøs source review linie for linie?!
Mindre arbejdspres og fokus på sikkerhed giver bedre kode. I et
eller andet omfang er det jo dét, Microsoft har lovet med deres
nye strategi. Men de understreger jo netop også, at det betyder
færre features.
Og det er naturligvis ingen garanti - de simple overflows og den
slags er nemme at komme udenom. Men der er altid risici, når man
har flere programmører, der arbejder sammen. Måske tror den ene,
at en funktion ikke behøver validere en strengs længde, fordi en
anden programmør allerede har gjort det. Det har han måske også,
men den tredje programmør, der bruger funktionen, tror bare, at
han kan smide hvad som helst i nakken på funktionen. Og gør det.
Hvis en stump kode skal udføres 1000 gange i sekundet, begynder
selv en meget lille validering at gøre ondt i performance.
Mvh.
Klaus.
| |
Jesper Louis Anderse~ (14-05-2004)
| Kommentar
Fra : Jesper Louis Anderse~ |
Dato : 14-05-04 09:33 |
|
Michael U. Hove <pots_72@e-mail.dk> wrote:
> Der er noget der har undret mig l?nge...
>
> Hvorfor er owerflows (heap, integer, stack, whatever) s? ekstremt
> udbredte blandt exploits?!
Det skyldes ganske simpelt at det er en opfoersel af programmet, som
programmoeren ikke regner med. Naar man sidder med en ide om at programmet
skal fungere, saa er det svaerere at spotte et sikkerhedsproblem det samme
sted i koden, med mindre man er opmaerksom paa problemet.
Overflows har det problem at de netop ikke er intended behaviour. Og saa
opstaar de.
> Ved at der findes metoder til at hj?lpe p? de v?rste problemer (OpenBSDs
> non-eksekverbare stack osv., Stackguard, libsafe, Boehm collectors osv.)
Du naevner de metoder der tager haand om problemet paa et niveau der er
meget grovkornet. Indenfor semantik har man i laengere tid rodet med
forsoeg paa at skabe noget mere finkornet kontrol.
> - at det er C/C++'s skyld!, er det s? fordi at sproget *er* for "sv?rt"
> at kode sikkert, ell. er det "the modern day" programm?r der ikke har
> *tid* til at skabe sikker kode pga. ?konomisk pres, deadlines,
> uretf?rdige chefer etc. etc.
Det er fordi det er svaert! For en sandsynliggoerelse, saa betragt OpenBSD
og antallet af patches der udkommer. Selv i et projekt hvor sikkerhed er
meget vaesenligt og tages meget serioest er der sikkerhedsfejl. Heldigvis
er deres impact som regel relativt smaa. At man saa ikke har tid, penge,
whatever goer det ikke nemmere at skrive sikker kode.
Det som Cyclone goer er at kigge paa de dele af C, der er svaere at behandle
programteoretisk. Ved saa at lave aendringer her (blandt andet ved oprettelse
af flere typer pointere) kan de saette bedre garantier for hvad der sker hvor
i programmet samtidig med at de kan indsaette runtime checks de steder hvor
det ikke kan lade sig goere at afgoere.
> Skal man g? v?k fra C/C++ (til hvad aner jeg ikke...) til at kode OS +
> apps. i fremtiden,
Det store problem er at finde et vaerktoej der er ligesaa maskinnaert og
samtidigt er sikkert. Er sproget Garbage Collected er det legende let at
kode i. Men hvad goer man naar man ikke har en GC i kernen? Den mulighed
man har leget med indtil videre er at bygge en lille stub i C og saa
konstruere resten af systemet ovenpaa denne i det sprog man nu foretraekker.
Kan stubben goeres tilstraekkeligt lille, saa kan den bevises korrekt.
Men skal man smide alle de programmer vaek vi allerede har skrevet og kan
vi bare tvinge programmoerer til at laere noget nyt og i givet fald, hvad
skal det vaere vi laerer dem af sprog?
> Findes der simpelthen ingen "genvej" til mere sikker kode, andet end
> minitu?s source review linie for linie?!
Joda. Enhver konstruktion der goer det nemmere for programmoeren vil lede
til kode med faerre fejl og derved ogsaa mere sikker kode. Skal programmoeren
ikke koncentrere sig om 3 ting, men kan noejes med 1, saa bliver sandsynligheden
for at han/hun fanger sikkerhedshullet stoerre. Hvis overflows ikke findes, saa
kan de ikke udnyttes. Runtime checks er nemme at tilfoeje. At fjerne dem igen
i det tilfaelde hvor der alligevel er sikkerhed for at der ikke laves overflow
er saa lidt svaerere.
Garbage collection fjerner malloc()/free() relaterede huller.
Et staerkede typesystem ville goere det af med signedness bugs. De fleste integer
overflows kan fanges ved at man trapper naar der laves overflow/underflow.
Man kunne skrue ned paa maengden af pointeraritmetik og anvendelsen af disse,
saa det ikke er programmoeren der eksplicit skal styre dem. Det ville betyde at
en stor klasse af problemer ligeledes ville forsvinde.
Men uden mere kontrol saasom proof carrying code eller anden formel verifikation,
saa er source review pt det bedste vaerktoej vi har.
> Og er dette overhovedet foreneligt med en kommerciel
> udviklingsmodel...noget tyder nemlig umiddelbart for mig p? det modsatte.
Det er i hvertfald meget faa der toer.
--
j.
| |
Kasper Dupont (14-05-2004)
| Kommentar
Fra : Kasper Dupont |
Dato : 14-05-04 16:55 |
|
Jesper Louis Andersen wrote:
>
> Garbage collection fjerner malloc()/free() relaterede huller.
Af alle de runtime foranstaltninger, der er blevet nævnt
er GC nok den dyreste. Og det er svært at lave en GC med
et forudsigeligt tidsforbrug. I nogen systemer kan man
simpelthen ikke leve med risikoen for, at programmet ikke
reagerer i et par sekunder fordi det er i gang med GC. En
GC der kører parallelt med programmet er muligt, men det
bliver meget sværere at afgøre liveness af objekter. Og
en race condition i GC vil være et alvorligt sikkerhedshul.
Der er flere problemer relateret til GC. Det kræver bla.
et stærkt typesystem og automatisk initialisering af alle
variable. Det bliver også sværere for programmøren at
garantere, at hukommelse bliver frigivet når den ikke skal
bruges mere. Et korrekt C program kan sagtens frigive et
stykke hukommelse selvom der ligger en håndfuld pointere
rundt omkring, der peger på den. Fragmentering og
lokalitet bliver også lidt sværere at holde styr på med
GC.
Selvfølgelig er der tilfælde, hvor det vil være rart med
GC. Men jeg mener det må være muligt, at lave runtime
check, der fanger malloc/free fejl uden GC. Det kræver
nogle lidt mere complicerede pointer typer og nogle
ekstra data strukturer. Men har ikke alle de uforudsigelige
problemer som følger med GC.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Jesper Louis Anderse~ (14-05-2004)
| Kommentar
Fra : Jesper Louis Anderse~ |
Dato : 14-05-04 18:17 |
|
Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> Af alle de runtime foranstaltninger, der er blevet n?vnt
> er GC nok den dyreste.
Dyreste? Langt det meste forskning viser at Garbage Collection
bevirker i hurtigere programmer end dem uden. Se [1].
> Og det er sv?rt at lave en GC med
> et forudsigeligt tidsforbrug. I nogen systemer kan man
> simpelthen ikke leve med risikoen for, at programmet ikke
> reagerer i et par sekunder fordi det er i gang med GC. En
> GC der k?rer parallelt med programmet er muligt, men det
> bliver meget sv?rere at afg?re liveness af objekter.
Se, det er rigtigt nok. Og med GC fjerner man heller ikke
problemet med memory leaks. Men det er stadigt nemmere for
programmoeren ikke at skulle taenke paa det hele tiden. Der
er noget forskning der gaar med at finde paa alternative
metoder til GC, hvor man har garantier for koeretiden af et
free()-kald (Region inference, se [2]). Alternativt kan
inkremental GC benyttes. Det er ikke saa meget svaerere at
holde et par ekstra invarianter.
> Og en race condition i GC vil v?re et alvorligt sikkerhedshul.
Ja, men det er stadig ikke saa mange linier kode man skal se
igennem, hvis samtlige programmer benytter den samme GC.
> Der er flere problemer relateret til GC. Det kr?ver bla.
> et st?rkt typesystem og automatisk initialisering af alle
> variable.
Jeg er glad for at du siger at sprog saasom Scheme, Lisp, Python
og Ruby har staerke typesystemer. Jeg er sikker paa at folkene
bag SML, Ocaml og Haskell er staerkt uenige heri. Et monomorft
sprog behoever ikke tag-bits i GC'en og det kan lede til en
masse vunden hastighed. Jeg kender et par implementationer der
udnytter dette. Ellers kan en konservativ GC benyttes, men de
er ikke rigtigt interessante IMO. Saa lange du har tags, kan du
sagtens lave ordentlig GC.
> Det bliver ogs? sv?rere for programm?ren at
> garantere, at hukommelse bliver frigivet n?r den ikke skal
> bruges mere. Et korrekt C program kan sagtens frigive et
> stykke hukommelse selvom der ligger en h?ndfuld pointere
> rundt omkring, der peger p? den.
Ja, men skal vi acceptere et saadant program som vaerende
korrekt? Det er et formelt definitionsspoergsmaal.
> Fragmentering og lokalitet bliver ogs? lidt sv?rere at
> holde styr p? med GC.
Ja, den bliver bedre. Se [3].
> Selvf?lgelig er der tilf?lde, hvor det vil v?re rart med
> GC. Men jeg mener det m? v?re muligt, at lave runtime
> check, der fanger malloc/free fejl uden GC. Det kr?ver
> nogle lidt mere complicerede pointer typer og nogle
> ekstra data strukturer. Men har ikke alle de uforudsigelige
> problemer som f?lger med GC.
Det kan man ogsaa goere, ja.
[1] http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
[2] http://citeseer.ist.psu.edu/tofte97regionbased.html
[3] http://ncstrl.cs.princeton.edu/expand.php?id=TR-482-94
--
j.
| |
Kasper Dupont (14-05-2004)
| Kommentar
Fra : Kasper Dupont |
Dato : 14-05-04 19:29 |
|
Jesper Louis Andersen wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
> >
> > Af alle de runtime foranstaltninger, der er blevet n?vnt
> > er GC nok den dyreste.
>
> Dyreste? Langt det meste forskning viser at Garbage Collection
> bevirker i hurtigere programmer end dem uden. Se [1].
OK, der kan selvfølgelig også være fordele ved GC. Du er
f.eks. fri for alle dine free kald. Jeg tænker mest på
at du en gang i mellem kan have store omkostninger. Det
amortiserede tidsforbrug behøver ikke være slemt for GC.
Men for at lave en fair sammenligning skal man også tage
højde for hukommelsesforbruget. Med en GC vil programmet
ofte opnå bedre performance jo mere ram det får lov at
bruge. Ikke fordi, du bruger pladsen til nogen relevante
data, men blot fordi du slipper for at bruge tid på at
ryde op. Jeg ved dog ikke, hvor længe tendense holder,
for man kunne nok forestille sig, at de meget spredte
objekter ikke er godt for lokaliteten.
>
> > Der er flere problemer relateret til GC. Det kr?ver bla.
> > et st?rkt typesystem og automatisk initialisering af alle
> > variable.
>
> Jeg er glad for at du siger at sprog saasom Scheme, Lisp, Python
> og Ruby har staerke typesystemer. Jeg er sikker paa at folkene
> bag SML, Ocaml og Haskell er staerkt uenige heri. Et monomorft
> sprog behoever ikke tag-bits i GC'en og det kan lede til en
> masse vunden hastighed. Jeg kender et par implementationer der
> udnytter dette. Ellers kan en konservativ GC benyttes, men de
> er ikke rigtigt interessante IMO. Saa lange du har tags, kan du
> sagtens lave ordentlig GC.
Du kan ikke lave en korrekt GC til C. Jeg kan skjule en
pointer så godt, at du ikke kan finde den. Og hvis du
ikke kan finde pointeren, så frigiver du noget hukommelse,
der stadig er i brug. Efterfølgende kan jeg så trække
pointeren frem fra hvor jeg nu har gemt den og derefernce
den.
Indrømmet, det ville være et afsindigt grimt C program.
Men ikke desto mindre, et korrekt C program, der ikke
ville virke efter det blev udsat for GC.
>
> > Det bliver ogs? sv?rere for programm?ren at
> > garantere, at hukommelse bliver frigivet n?r den ikke skal
> > bruges mere. Et korrekt C program kan sagtens frigive et
> > stykke hukommelse selvom der ligger en h?ndfuld pointere
> > rundt omkring, der peger p? den.
>
> Ja, men skal vi acceptere et saadant program som vaerende
> korrekt? Det er et formelt definitionsspoergsmaal.
Men det er korrekt i forhold til C standarden. C har
nogle styrker, men jeg skal indrømme, at ulemperne ved
C efterhånden bliver tydligere og tydligere.
>
> > Fragmentering og lokalitet bliver ogs? lidt sv?rere at
> > holde styr p? med GC.
>
> Ja, den bliver bedre. Se [3].
Det kan ikke siges så firkantet. Vi kan sammenlinge
specifikke strategier med og uden GC, men jeg ved ikke
voldsomt meget om det. Jeg har dog læst, at
stop-and-copy-GC havde problemer med lokaliteten. Til
gengæld er stop-and-copy perfekt til at læse problemet
med fragmentering. Jeg kan ikke huske, hvad bogen jeg
læste det i hedder, men jeg ved godt hvad det er for en
jeg skal lede efter.
De cache effektive algoritmer jeg kender vil alligevel
være fuldstændigt ligeglade med, om der bruges GC eller
ej. For de allocerer alligevel bare et enkelt stort
hukommelsesområde og lægger så tingene deri på den
mest praktiske måde. Og når man er færdig kan hele
området frigives på en gang.
>
> > Selvf?lgelig er der tilf?lde, hvor det vil v?re rart med
> > GC. Men jeg mener det m? v?re muligt, at lave runtime
> > check, der fanger malloc/free fejl uden GC. Det kr?ver
> > nogle lidt mere complicerede pointer typer og nogle
> > ekstra data strukturer. Men har ikke alle de uforudsigelige
> > problemer som f?lger med GC.
>
> Det kan man ogsaa goere, ja.
I modsætning til GC, så tror jeg det er muligt at gøre
korrekt i C. Man skal selvfølgelig bruge nogen tricks for
at ikke skulle huske på alle de hukommelsesområder, man en
gang har frigivet.
Tildel hver allocering et 64 bits løbenummer. Gem dette
løbenummer i en plads i et array, og gem både løbenummer og
array index i pointeren. For at validere en pointer checker
man først, om array index er indenfor arrayet. Dernæst
checker man om der står den rigtige værdi på pladsen i
arrayet. free skal bare frigive den egentlige hukommelse,
og overskriver løbenummeret i arrayet. Frie array indgange
kan huskes med en kædet liste. Man kan starte sin 64 bits
tæller med en værdi, der er større end det størst mulige
index, så risikerer man aldrig at et array index i en fri
celle er identisk med et gammelt løbenummer.
>
> [1] http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
> [2] http://citeseer.ist.psu.edu/tofte97regionbased.html
> [3] http://ncstrl.cs.princeton.edu/expand.php?id=TR-482-94
>
> --
> j.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Povl H. Pedersen (16-05-2004)
| Kommentar
Fra : Povl H. Pedersen |
Dato : 16-05-04 08:43 |
|
In article <40a40d1d$0$183$edfadb0f@dread11.news.tele.dk>, Michael U. Hove wrote:
> - at det er C/C++'s skyld!, er det så fordi at sproget *er* for "svært"
> at kode sikkert, ell. er det "the modern day" programmør der ikke har
> *tid* til at skabe sikker kode pga. økonomisk pres, deadlines,
> uretfærdige chefer etc. etc.
Nej. Problemet er at der er kommet en masse mennesker ind i branchen,
som ikke har lært at tænke, lave inputvalidering etc. Det er ikke
væsentligt mere besværligt at skrive god kode. Kræver bare lidt
disciplin, og at man er bevidst om at der er "onde" brugere.
Et sprog som ASP har givet en masse af de samme problemer, se
eksempelvis Valus sagen. Man ansætter en klump "udviklere" af
lav kvalitet, eller copy/paste programmører. Og de tænker ikke
over at de data de får fra brugeren kan være ændrede. De har jo
lave user-side inputvalidering (JavaScript), men det kan brugeren
også slå fra.
Andre sprog som Perl har også haft problemet. Eksempelvis at man
udfører shellcode baseret på user input. Så problemet er generelt
manglende inputvalidering.
I starten var C svært, og man fik da lavet run-away pointers,
men efterhånden som man lærer det bliver det langt lettere at
håndtere.
> Skal man gå væk fra C/C++ (til hvad aner jeg ikke...) til at kode OS +
> apps. i fremtiden,
Man kan bruge Forth (bruges til OpenFirmware drivere), og det er
godt på mange måder, men har også småproblemer.
> Findes der simpelthen ingen "genvej" til mere sikker kode, andet end
> minituøs source review linie for linie?!
Jo. Fornuftig kodeskrivning fra starten.
> Og er dette overhovedet foreneligt med en kommerciel
> udviklingsmodel...noget tyder nemlig umiddelbart for mig på det modsatte.
Den kommercielle udviklingsmodel burde straffe dem der ikke laver
god kode, og derfor burde den være forenelig.
God kode tager ikke 10% mere at skrive. Men kræver viden og
erfaring som måske ikke haves af discountprogrammører. Sikker
programmering er nemlig typisk ikke engang med i de fleste
bøger som ofte har skodkode som eksempler. Så udviklerne er
omgivet af skod de lader sig inspirere fra.
--
Povl H. Pedersen - NoSpam@my.terminal.dk (yes - it works)
Get 5% discount on VMWare use discount/referral code: MRC-POVPED260
| |
Michael Legart (16-05-2004)
| Kommentar
Fra : Michael Legart |
Dato : 16-05-04 09:13 |
|
On 2004-05-16, Povl H. Pedersen <povlhp@povl-h-pedersens-computer.local> wrote:
>> Findes der simpelthen ingen "genvej" til mere sikker kode, andet end
>> minituøs source review linie for linie?!
>
> Jo. Fornuftig kodeskrivning fra starten.
Du faar det til at lyde temmelig nemt. Se paa et projekt som
OpenSSH... det blev startet fordi der konstant blev opdaget
sikkerhedshuller i den kommercielle SSH.
OpenSSH folkene havde altsaa eet maal: bygge en ssh implementation
uden huller. Jeg kan tage fejl, men de folk der er bag er ikke
ligefrem nybegyndere... men hvad er der sket?
--
hestdesign.info - we put the hest in .com
| |
Povl H. Pedersen (16-05-2004)
| Kommentar
Fra : Povl H. Pedersen |
Dato : 16-05-04 11:38 |
|
In article <slrncae8k8.rat.michaelnospam@kamel.legart.dk>, Michael Legart wrote:
> On 2004-05-16, Povl H. Pedersen <povlhp@povl-h-pedersens-computer.local> wrote:
>>> Findes der simpelthen ingen "genvej" til mere sikker kode, andet end
>>> minituøs source review linie for linie?!
>>
>> Jo. Fornuftig kodeskrivning fra starten.
>
> Du faar det til at lyde temmelig nemt. Se paa et projekt som
> OpenSSH... det blev startet fordi der konstant blev opdaget
> sikkerhedshuller i den kommercielle SSH.
>
> OpenSSH folkene havde altsaa eet maal: bygge en ssh implementation
> uden huller. Jeg kan tage fejl, men de folk der er bag er ikke
> ligefrem nybegyndere... men hvad er der sket?
Kan ikke huske hvor fejlene var, men så vidt jeg husker er mindst
et af dem i et library der benyttes af OpenSSH. Men man ved ikke
hvor mange udviklere der har været involveret, og om de alle har været
gode.
--
Povl H. Pedersen - NoSpam@my.terminal.dk (yes - it works)
Get 5% discount on VMWare use discount/referral code: MRC-POVPED260
| |
Kent Friis (16-05-2004)
| Kommentar
Fra : Kent Friis |
Dato : 16-05-04 09:45 |
|
Den Sun, 16 May 2004 07:42:30 +0000 (UTC) skrev Povl H. Pedersen:
>
> I starten var C svært, og man fik da lavet run-away pointers,
> men efterhånden som man lærer det bliver det langt lettere at
> håndtere.
Apropos, plejer GCC -Wall ikke at advare om at en variabel / pointer
bliver brugt før den er initialiseret? Det synes jeg før den har
gjort.
Jeg havde sådan et problem igår, hvor et program virkede når jeg
compilede det, men når en kammarat compilede samme program, virkede
det ikke. Så min version af GCC må have initialiseret pointeren til 0,
hvor hans ikke gjorde.
Hvordan slår man det check til?
Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/
| |
Kasper Dupont (16-05-2004)
| Kommentar
Fra : Kasper Dupont |
Dato : 16-05-04 09:59 |
|
Kent Friis wrote:
>
> Den Sun, 16 May 2004 07:42:30 +0000 (UTC) skrev Povl H. Pedersen:
> >
> > I starten var C svært, og man fik da lavet run-away pointers,
> > men efterhånden som man lærer det bliver det langt lettere at
> > håndtere.
>
> Apropos, plejer GCC -Wall ikke at advare om at en variabel / pointer
> bliver brugt før den er initialiseret? Det synes jeg før den har
> gjort.
Jo, det mener jeg den gør, hvis den opdager det.
Optimeringsniveauet kan godt have inflydelse på
hvornår den giver warnings. Der er vist nok et
eller andet med, at den kun giver warnings hvis
du kører med minimum -O1.
I øvrigt kan den også godt give warnings, selvom
en variabel tydligvis bliver initialiseret før
den bliver brugt.
Her er et scenarie, der ikke giver nogen warning
på trods af at jeg læser en uinitialiseret
variabel:
int f(int *p)
{
return *p;
}
int main()
{
int v;
return f(&v);
}
>
> Jeg havde sådan et problem igår, hvor et program virkede når jeg
> compilede det, men når en kammarat compilede samme program, virkede
> det ikke. Så min version af GCC må have initialiseret pointeren til 0,
> hvor hans ikke gjorde.
Der er flere faktorer, der spiller ind. Ovenstående
program giver forskelligt resultat med forskellige
optimeringsniveau. Desuden tror jeg ikke det er gcc,
der initialiserer noget til 0. Det er et spørgsmål
om, at alt hukommelse alloceret fra operativsystemet
som udgangspunkt er nulstillet. Så første gang du
bruger hukommelsen vil den indholde nul, men ikke
efterfølgende. Det gælder også for stakken, så en
lokal variabel kan sagtens indeholde noget fra et
tidligere funktionskald.
>
> Hvordan slår man det check til?
Hjælper "-O1 -Wall -W"?
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Kent Friis (16-05-2004)
| Kommentar
Fra : Kent Friis |
Dato : 16-05-04 10:49 |
|
Den Sun, 16 May 2004 10:59:03 +0200 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> Den Sun, 16 May 2004 07:42:30 +0000 (UTC) skrev Povl H. Pedersen:
>> >
>> > I starten var C svært, og man fik da lavet run-away pointers,
>> > men efterhånden som man lærer det bliver det langt lettere at
>> > håndtere.
>>
>> Apropos, plejer GCC -Wall ikke at advare om at en variabel / pointer
>> bliver brugt før den er initialiseret? Det synes jeg før den har
>> gjort.
>
> Jo, det mener jeg den gør, hvis den opdager det.
> Optimeringsniveauet kan godt have inflydelse på
> hvornår den giver warnings. Der er vist nok et
> eller andet med, at den kun giver warnings hvis
> du kører med minimum -O1.
Der var den, TAK. Hvis -O1 havde været slået til kunne vi have sparet
en masse debugging.
>> Jeg havde sådan et problem igår, hvor et program virkede når jeg
>> compilede det, men når en kammarat compilede samme program, virkede
>> det ikke. Så min version af GCC må have initialiseret pointeren til 0,
>> hvor hans ikke gjorde.
>
> Der er flere faktorer, der spiller ind. Ovenstående
> program giver forskelligt resultat med forskellige
> optimeringsniveau. Desuden tror jeg ikke det er gcc,
> der initialiserer noget til 0. Det er et spørgsmål
> om, at alt hukommelse alloceret fra operativsystemet
> som udgangspunkt er nulstillet.
>
> Så første gang du
> bruger hukommelsen vil den indholde nul, men ikke
> efterfølgende. Det gælder også for stakken, så en
> lokal variabel kan sagtens indeholde noget fra et
> tidligere funktionskald.
Det interessante var at den ene exe-fil konsekvent gjorde rigtigt, og
den anden konsekvent gjorde forkert, også selvom vi kørte dem på
samme maskine.
Ok, det er da muligt at den funktiond der blev kaldt lige inden
tilfældigvis har lagt et 0 på stakken det rigtige sted på den ene
compiler, og ikke på den anden.
>> Hvordan slår man det check til?
>
> Hjælper "-O1 -Wall -W"?
-O1 -Wall var nok. Hvad gør -W alene?
Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/
| |
Jacob Atzen (16-05-2004)
| Kommentar
Fra : Jacob Atzen |
Dato : 16-05-04 11:00 |
|
Kent Friis <nospam@nospam.invalid> writes:
> -O1 -Wall var nok. Hvad gør -W alene?
RTFM: 'info gcc' -> Invoking GCC -> Warning Options:
`-W'
Print extra warning messages for these events:
...
--
Med venlig hilsen
- Jacob Atzen
| |
Kent Friis (16-05-2004)
| Kommentar
Fra : Kent Friis |
Dato : 16-05-04 11:07 |
|
Den 16 May 2004 12:00:26 +0200 skrev Jacob Atzen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> -O1 -Wall var nok. Hvad gør -W alene?
>
> RTFM: 'info gcc' -> Invoking GCC -> Warning Options:
>
> `-W'
> Print extra warning messages for these events:
> ...
Ja, men -Wall er jo warnings for ALT, hvad er så fidusen i at tilføje
-W også?
Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/
| |
Kasper Dupont (16-05-2004)
| Kommentar
Fra : Kasper Dupont |
Dato : 16-05-04 11:15 |
|
Kent Friis wrote:
>
> Ja, men -Wall er jo warnings for ALT,
Det troede jeg også en gang.
> hvad er så fidusen i at tilføje -W også?
Flere warnings (nogen gange lidt for mange).
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk
I'd rather be a hammer than a nail.
| |
Anders Wegge Jakobse~ (13-05-2004)
| Kommentar
Fra : Anders Wegge Jakobse~ |
Dato : 13-05-04 21:35 |
|
"Troels" == Troels Arvin <troels@arvin.dk> writes:
> On Thu, 13 May 2004 20:12:45 +0000, Andreas Plesner Jacobsen wrote:
>> Skarpt i hælene på visse personers ide om at en firewall altid er
>> løsningen har Eeye fundet ikke mindre end 4 fejl i Symantec firewalls -
>> hvoraf 3 (TRE!) giver mulighed for at udføre kode på den angrebne
>> maskine
> Fantastisk. Har du i øvrigt en reference?
Alle 3 exploits er beskrevet på Bugtraq, så mon ikke du kan finde dem
på http://www.securityfocus.org
--
/Wegge < http://outside.bakkelygaard.dk/~wegge/>
echo mail: !#^."<>"|tr "<> mail:" dk@wegge
| |
|
|