---

Givet den retning som diskussionen herinde har taget fornyligt, ville
jeg lige give et heads up paa dette reviderede svar i OSS'en til punktet
"Opsætning af Mozilla Firefox":

I skrivende stund har Firefox ikke nogle specifikke problemer.

Du kan naturligvis vælge at slå Java og JavaScript fra, og du kan vælge
at skifte fra tilstanden 'Save all files to folder: Desktop' til 'Ask me
where to save every file'.

Det kunne være rart hvis Firefox tillod en opdeling af websites i zoner,
således man kunne nøjes med at give visse websites adgang til at udføre
JavaScript, etc. men det falder under kategorien 'Ønskværdige
forbedringer' og ikke 'Pinlige sikkerhedsfejl'.

Selvom Firefox ikke har nogle kendte, specifikke problemer, er det værd
at huske, at den har heller ikke gennemgået en sikkerhedsanalyse, og der
er ingen tvivl om, at udviklernes manglende fokus på sikkerhed på et
tidspunkt vil resultere i, at brugere af Firefox bliver næsten lige så
udsatte som brugere af IE er det i dag.

Denne forfatter forventer at sikkerheden i webbrowsere først vil få
ordenlig fokus sidst i år 2005 eller midt i år 2006. Det er den samme
cyklus som alle andre produkter: Først virker det, så bliver det
udbredt, og derefter bliver der gjort en indsats for sikkerheden.


--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Den Tue, 19 Oct 2004 17:40:49 +0200 skrev Alex Holst:
>
> Det kunne være rart hvis Firefox tillod en opdeling af websites i zoner,
> således man kunne nøjes med at give visse websites adgang til at udføre
> JavaScript, etc. men det falder under kategorien 'Ønskværdige
> forbedringer' og ikke 'Pinlige sikkerhedsfejl'.

"Zoner" plejer da at høre under "pinlige sikkerhedsfejl".

Når hvad der må udføres afhænger af hvor siden kommer fra, kommer
alle problemerne med hvor tror browseren at siden kommer fra, og
hvor kommer siden i virkeligheden fra, som vi har set masser af
gange hos browsere der implementerer zoner.

Er en funktion derimod generelt slået fra, eller endnu bedre slet
ikke implementeret, er det meget sværere at få fat i den alligevel.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:
> "Zoner" plejer da at høre under "pinlige sikkerhedsfejl".
>
> Når hvad der må udføres afhænger af hvor siden kommer fra, kommer
> alle problemerne med hvor tror browseren at siden kommer fra, og
> hvor kommer siden i virkeligheden fra, som vi har set masser af
> gange hos browsere der implementerer zoner.

Lige nu har jeg slaaet JavaScript til paa alle websites jeg besoeger.
Det kan kun blive bedre, hvis jeg kan angive hvilke sites der har lov
til at udfoere JavaScript i Firefox.

Eftersom Firefox er implementeret i JavaScript, har den allerede en
komplex intern struktur der angiver at JavaScripts fra websites kun har
lov til visse ting, mens dens egen JavaScript har lov til udfoere alle
mulige opgaver. Der skal nok vaere et par hundrede fejl i *det* design.

Om noget, saa ville en specificering af hvilke websites der overhovedet
havde lov til at udfoere JavaScript kode virke som endnu en forhindring
for angriberen.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Den Wed, 20 Oct 2004 00:47:50 +0200 skrev Alex Holst:
> Kent Friis wrote:
>> "Zoner" plejer da at høre under "pinlige sikkerhedsfejl".
>>
>> Når hvad der må udføres afhænger af hvor siden kommer fra, kommer
>> alle problemerne med hvor tror browseren at siden kommer fra, og
>> hvor kommer siden i virkeligheden fra, som vi har set masser af
>> gange hos browsere der implementerer zoner.
>
> Lige nu har jeg slaaet JavaScript til paa alle websites jeg besoeger.
> Det kan kun blive bedre, hvis jeg kan angive hvilke sites der har lov
> til at udfoere JavaScript i Firefox.

Man går da bare ind under prefe... nej, det gælder sg* kun popups,
hvad er nu det for noget snyd?

> Eftersom Firefox er implementeret i JavaScript, har den allerede en
> komplex intern struktur der angiver at JavaScripts fra websites kun har
> lov til visse ting, mens dens egen JavaScript har lov til udfoere alle
> mulige opgaver. Der skal nok vaere et par hundrede fejl i *det* design.

Er du sikker på det? Jeg var overbevist om at det er C++-baseret XUL, og
det javascript-baserede først kommer ind i billedet ved diverse
extensions.

Hvis du har ret, vil jeg helt klar også mene det er et meget uheldigt
design.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Alex Holst" skrev d. 19-10-04 16:41 dette indlæg :
>
> Givet den retning som diskussionen herinde har taget fornyligt, ville
> jeg lige give et heads up paa dette reviderede svar i OSS'en til
punktet
> "Opsætning af Mozilla Firefox":
>
> I skrivende stund har Firefox ikke nogle specifikke problemer.
>
> Du kan naturligvis vælge at slå Java og JavaScript fra, og du kan
vælge
> at skifte fra tilstanden 'Save all files to folder: Desktop' til 'Ask
me
> where to save every file'.
>
> Det kunne være rart hvis Firefox tillod en opdeling af websites i
zoner,
> således man kunne nøjes med at give visse websites adgang til at
udføre
> JavaScript, etc. men det falder under kategorien 'Ønskværdige
> forbedringer' og ikke 'Pinlige sikkerhedsfejl'.
>
> Selvom Firefox ikke har nogle kendte, specifikke problemer, er det
værd
> at huske, at den har heller ikke gennemgået en sikkerhedsanalyse, og
der
> er ingen tvivl om, at udviklernes manglende fokus på sikkerhed på et
> tidspunkt vil resultere i, at brugere af Firefox bliver næsten lige så

> udsatte som brugere af IE er det i dag.
>
> Denne forfatter forventer at sikkerheden i webbrowsere først vil få
> ordenlig fokus sidst i år 2005 eller midt i år 2006. Det er den samme
> cyklus som alle andre produkter: Først virker det, så bliver det
> udbredt, og derefter bliver der gjort en indsats for sikkerheden.
>
>
> --
> I prefer the dark of the night, after midnight and before four-thirty,
> when it's more bare, more hollow. http://a.mongers.org
>
> OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

Jeg ved da ikke om man kan sige, at der ikke er problemer med mozilla
firefox.
Det er da ikke muligt at gå på netbank med den, ihvertfald ikke danske
netbank.

Fra andre forums ved jeg også. at der er problemer med netop
homebanking, og mozilla firefox.

--
Leveret af:
http://www.kandu.dk/
"Vejen til en hurtig løsning"

---

"mitri123" <mitri123.news@kandu.dk> skrev i en meddelelse
news:4176e6b8$0$176$edfadb0f@dtext02.news.tele.dk...

Hej,

> Det er da ikke muligt at gå på netbank med den, ihvertfald ikke danske
> netbank.
>
> Fra andre forums ved jeg også. at der er problemer med netop
> homebanking, og mozilla firefox.

Hmm, de problemer er jeg ikke bekendt med. Min firefox har ikke problemer
med netbank - hverken Nordea, Danske bank eller Diskonto banken. Det
forleder mig til at tro, at du ikke har konfigureret den korrekt.

Venligst
Peter Kruse
http://www.csis.dk

---

>
> Jeg ved da ikke om man kan sige, at der ikke er problemer med mozilla
> firefox.
> Det er da ikke muligt at gå på netbank med den, ihvertfald ikke danske
> netbank.
>
> Fra andre forums ved jeg også. at der er problemer med netop
> homebanking, og mozilla firefox.

Problemer med netbank har jo egentlig ikke noget med browseren at gøre.
Det er blot banken der laver deres software så det kun kan køre under
Internet Explorer. Selve browseren har ingen problemer med at køre
webbank. Det kræver bare at banken gider at lave deres netbanksoftware,
så det virker i andre browsere end IE. Og det er nogle banker der godt
kan finde ud af.

Mvh
Jeppe Larsen

---

"Alex Holst" skrev i en meddelelse

> Selvom Firefox ikke har nogle kendte, specifikke problemer, er det værd
> at huske, at den har heller ikke gennemgået en sikkerhedsanalyse, og der
> er ingen tvivl om, at udviklernes manglende fokus på sikkerhed på et
> tidspunkt vil resultere i, at brugere af Firefox bliver næsten lige så
> udsatte som brugere af IE er det i dag.

"... Secunia advarer om en række nye sårbarheder i flere browsere,
heriblandt to nye sikkerhedshuller i Microsoft Internet Explorer. Selskabet
rapporterer onsdag om nye sårbarheder i Mozilla, Firefox, Opera Safari,
Konqueror og altså Internet Explorer. ..."

Hele siden:
http://www.computerworld.dk/sikkerhed/default.asp?Mode=2&AutoArticleID=19976

Mvh John

---

"John" <nogen@pladderballe.ok> skrev i en meddelelse
news:41777b2f$0$195$edfadb0f@dread12.news.tele.dk...

Hej John,

> "... Secunia advarer om en række nye sårbarheder i flere browsere,
> heriblandt to nye sikkerhedshuller i Microsoft Internet Explorer.
> Selskabet
> rapporterer onsdag om nye sårbarheder i Mozilla, Firefox, Opera Safari,
> Konqueror og altså Internet Explorer. ..."

Den mest alvorlige af de sårbarheder, som velsagtens gør dette til en
historie, er en variation af træk-og-slip sårbarheden i IE.

Den sårbarhed, som vedrører de øvrige browsere er mindre væsentlig.

Venligst
Peter Kruse
http://www.csis.dk

---

"Peter Kruse" skrev i en meddelelse

> Hej John

> Den mest alvorlige af de sårbarheder, som velsagtens gør dette til en
> historie, er en variation af træk-og-slip sårbarheden i IE.
>
> Den sårbarhed, som vedrører de øvrige browsere er mindre væsentlig.
>
> Venligst
> Peter Kruse

Hej Peter, tak for svaret!

Så kan vi, der trods de mange sårbarheder kører IE uden problemer, blot
vente på, at Bill igen finder sine lappesager frem :)

Mvh John

---

"John" <nogen@pladderballe.ok> skrev i en meddelelse
news:4177c0ce$0$301$edfadb0f@dread12.news.tele.dk...

Hej John,

> Så kan vi, der trods de mange sårbarheder kører IE uden problemer, blot
> vente på, at Bill igen finder sine lappesager frem :)

Du kan i mellemtiden sætte en killbit på Shell.Explorer ActiveX objektet.
Det vil afholde koden fra at blive afviklet og altså lukke hullet.
Yderligere oplysninger om dette indgreb kan iøvrigt findes hos Microsoft på
følgende adresse: http://support.microsoft.com/?kbid=240797

Du kan også finde en lille reg-fil på vores hjemmeside (kredit til Thor
Larholm), som foretager indgrebet.

Venligst
Peter Kruse
http://www.csis.dk

---

"Peter Kruse" skrev i en meddelelse

> Du kan i mellemtiden sætte en killbit på Shell.Explorer ActiveX objektet.
> Det vil afholde koden fra at blive afviklet og altså lukke hullet.
> Yderligere oplysninger om dette indgreb kan iøvrigt findes hos Microsoft
på
> følgende adresse: http://support.microsoft.com/?kbid=240797

> Du kan også finde en lille reg-fil på vores hjemmeside (kredit til Thor
> Larholm), som foretager indgrebet

Tak for tippet Peter; det vil jeg kigge nærmere på.

Mvh John

---

Alex Holst skrev:


> Givet den retning som diskussionen herinde har taget fornyligt,
> ville jeg lige give et heads up paa dette reviderede svar i OSS'en
> til punktet "Opsætning af Mozilla Firefox":

> I skrivende stund har Firefox ikke nogle specifikke problemer.

Hvad med disse?

http://www.securityfocus.com/archive/1/378632/2004-10-15/2004-10-21/2

---

On søn, 2004-10-24 at 01:59 +0200, Peder Vendelbo Mikkelsen wrote:
> Hvad med disse?
>
> http://www.securityfocus.com/archive/1/378632/2004-10-15/2004-10-21/2

Lynx/Links bruger alt memory, og quiter så når der ikke er mere at tage,
ikke noget sikkerheds problem på et Linux system, fordi den er en
multiuser platform og tager højde for den slags, den DoS situation
indlæggets forfatter mener eksistere er i hans fantasi fordi han ikke
forstår at Linux er et multi-user system, så den er bygget til at
overleve den slags fejl.

Så visse ting får Mozilla til at give op og dø, igen ikke noget
sikkerheds problem, men det er da rart at buggen er fundet så de kan se
på deres HTMl indlæser og gøre programmet mere stabilt.

Excessive COL SPAN in TBODY causes Opera to go down in flames,
attempting to make a reference to uninitialized memory. Probably
can be exploited in right conditions.

Dette kunne være et user space sikkerheds problem, men måske er det bare en crash bug.

Detter er dk.edb.sikkerhed ikke dk.software.bugs

Med mindre vi køre programmerne på Windows, så er Lynx/links et system
nedbrydene sikkerheds problem. Opera fejlen, hvis det ikke bare er en
crash bug, et alvorligt sikkerheds hul der giver fuldt adgang til
systemet og Mozilla crashing gør måske Windows ustabil.

Det er ikke nok bare at køre programmer baseret på en mere sikker
technologi (Ingen ActiveX, ikke integreret i OS'et, etc), du skal også
havde et operativsystem der underbygger sikkerheden, hvis du vil havde
fuld valuta for pengene ellers er det som at købe en bil med airbags,
men ingen bremser.

---

Den Sun, 24 Oct 2004 04:12:10 +0200 skrev Steen Eugen Poulsen:
> On søn, 2004-10-24 at 01:59 +0200, Peder Vendelbo Mikkelsen wrote:
>> Hvad med disse?
>>
>> http://www.securityfocus.com/archive/1/378632/2004-10-15/2004-10-21/2
>
> Lynx/Links bruger alt memory, og quiter så når der ikke er mere at tage,
> ikke noget sikkerheds problem på et Linux system, fordi den er en
> multiuser platform og tager højde for den slags, den DoS situation
> indlæggets forfatter mener eksistere er i hans fantasi fordi han ikke
> forstår at Linux er et multi-user system, så den er bygget til at
> overleve den slags fejl.

Vrøvl.

Denial of service betyder blot at man lukker eller blokerer en maskine,
service eller et program. I dette tilfælde er det så browseren der
bliver lavet et DOS angreb imod, ikke maskinen.

Derudover er det meget varieret hvad Linux'en gør i OOM situationen.
Med OOM-killer bliver der gjort et forsøg på at ramme den rigtige
process, men uden er det tilfældigt hvilket program der lukket. Og
hvis det var det forkerte program, har vi en ny OOM situation to
sekunder senere, når den igen har brugt al RAM'en. Og et nyt
tilfældigt program bliver lukket. Med 1000 brugere på maskinen kan
den nå at lukke mange forkerte programmer før den rammer synderen.

> Så visse ting får Mozilla til at give op og dø, igen ikke noget
> sikkerheds problem,

En buffer overrun med tilfældige data får et program til at crashe. En
buffer overrun med velvalgte data giver adgang til maskinen.

Første skridt er at få browseren til at crashe. Næste skridt er så at
analysere stack og registre på crash-tidspunktet i en debugger, og
dernæst kan man så konstruere de velvalgte data der giver adgang til
maskinen.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis <nospam@nospam.invalid> wrote:

> Derudover er det meget varieret hvad Linux'en g?r i OOM situationen.
> Med OOM-killer bliver der gjort et fors?g p? at ramme den rigtige
> process, men uden er det tilf?ldigt hvilket program der lukket. Og
> hvis det var det forkerte program, har vi en ny OOM situation to
> sekunder senere, n?r den igen har brugt al RAM'en. Og et nyt
> tilf?ldigt program bliver lukket. Med 1000 brugere p? maskinen kan
> den n? at lukke mange forkerte programmer f?r den rammer synderen.

Hvorfor skal den dog helt derud?

hint: getrlimit(2), setrlimit(2) og gode default settings af samme
for shells...

--
j.

---

On søn, 2004-10-24 at 07:46 +0000, Kent Friis wrote:
> Derudover er det meget varieret hvad Linux'en gør i OOM situationen.
> Med OOM-killer bliver der gjort et forsøg på at ramme den rigtige
> process, men uden er det tilfældigt hvilket program der lukket. Og
> hvis det var det forkerte program, har vi en ny OOM situation to
> sekunder senere, når den igen har brugt al RAM'en. Og et nyt
> tilfældigt program bliver lukket. Med 1000 brugere på maskinen kan
> den nå at lukke mange forkerte programmer før den rammer synderen.

Der er noget du har misset her, Lynx og Links er ikke et bevist OOM
program, de er bare ganske almindelige browsers der henter memory indtil
systemet fortæller at der ikke er mere at hente og så terminere de,
hvilket så frigiver den hukommelse.

Da Windows ikke kan håndtere swapping særligt godt vil det på denne
platform skabe en situation hvor systemet stopper med at virke. Hvis
Windows systemet selv får hukommelses fejl vil det desuden crashe
maskinen.

PÃ¥ Linux har det en vis effekt at systemet begynder at bruge swap, men
er ellers ikke et stort problem. Jeg har da iværtifald skrevet denne
besked mens lynx crashed. :)

> En buffer overrun med tilfældige data får et program til at crashe. En
> buffer overrun med velvalgte data giver adgang til maskinen.
>
> Første skridt er at få browseren til at crashe. Næste skridt er så at
> analysere stack og registre på crash-tidspunktet i en debugger, og
> dernæst kan man så konstruere de velvalgte data der giver adgang til
> maskinen.

Den funktion der har en situation den ikke tager højde for er en
rekursiv funktion, der ikke håndterer at en situation kan skabes hvor
den bliver udført så mange gange som den gør og den fejler så på et
tidspunkt med en memory fejl når den forsøger at en push til stack
memory området. Dette er ikke de samme some buffer overflow:

Et buffer overflow udnytter hvordan vært enkelt functions stack entry
ser ud.

<program stack buffer xx bytes>
<stack>
<register>
<stack>
<register>
<stack>
<register>

Ved at skabe en situation hvor størrelsen på funktionens stack buffer er
støre en det forventede skaber du en situation hvor <registrene> kan
overskrives med planlagt information, registrene er code programmet
kalder, så i en web server kunne de udføre et exec kald og få terminal
adgang, eller hvis det lovlige <stack> område er stort nok kan de ligge
en virus ind som den ændrede <register> information kan kalde.

En rekursiv funktion fylder stacken med <stack><register> entries,
indtil den får at vide at der ikke er mere plads, på intet tidspunkt er
<stack><register> systemet I en situation hvor <registrene> er
overskrevet.

Du er vist blevet lidt for forvent med alle de stack overflows, som har
ramt især Microsoft programmer, pga. dårlig sikkerheds programmering og
tror du er blevet den store specialist, men programmering er en hel del
mere kompliceret end hvad man høre om i pressen.

Så på ingen platform er der tale om andet end en bug og det høre ikke
til i en sikkerheds diskussions gruppe.

---

Steen Eugen Poulsen <s.e.poulsen@gmail.com> wrote:

> En rekursiv funktion fylder stacken med <stack><register> entries,
> indtil den f?r at vide at der ikke er mere plads, p? intet tidspunkt er
> <stack><register> systemet I en situation hvor <registrene> er
> overskrevet.
>
> Du er vist blevet lidt for forvent med alle de stack overflows, som har
> ramt is?r Microsoft programmer, pga. d?rlig sikkerheds programmering og
> tror du er blevet den store specialist, men programmering er en hel del
> mere kompliceret end hvad man h?re om i pressen.

Nemlig. Blandt andet gaelder ovenstaaende omkring rekursive funktioner
ikke altid. Rekursive funktioner, hvor rekursionen er et halekald, kan
ofte transformeres til en loekke hvorfor de ikke laver samme
stakeksplosion som du siger.

Jeg kan heller ikke se hvor din analogi skal anvendes.
resource exhaustion af stack-space er ikke det samme som resource
exhaustion af memory, CPU-tid, fildescriptorer etc.

Men - det laver ikke om paa at det er et DoS attack. Hvis en side kan
smadre en browser, saa kan du potentielt miste arbejde. Hvordan man
saa vil behandle problemet, hvis siden er saa stor at den ikke kan
vaere i hukommelse+swap er en lidt anden sag. Men er problemet ikke at
en relativ lille side skaber et memory leak i browserens parser?

Jeg finder Alex oprindelige indlaeg interessant. Firefox er ikke en
sikker browser grundet programmoerers omtanke, men fordi der ikke er
nogen der har haft den som maal.

--
j.

---

Den Sun, 24 Oct 2004 15:20:02 +0200 skrev Steen Eugen Poulsen:
> On søn, 2004-10-24 at 07:46 +0000, Kent Friis wrote:
>> Derudover er det meget varieret hvad Linux'en gør i OOM situationen.
>> Med OOM-killer bliver der gjort et forsøg på at ramme den rigtige
>> process, men uden er det tilfældigt hvilket program der lukket. Og
>> hvis det var det forkerte program, har vi en ny OOM situation to
>> sekunder senere, når den igen har brugt al RAM'en. Og et nyt
>> tilfældigt program bliver lukket. Med 1000 brugere på maskinen kan
>> den nå at lukke mange forkerte programmer før den rammer synderen.
>
> Der er noget du har misset her, Lynx og Links er ikke et bevist OOM
> program, de er bare ganske almindelige browsers der henter memory indtil
> systemet fortæller at der ikke er mere at hente og så terminere de,
> hvilket så frigiver den hukommelse.

Og at målet for angrebet terminerer/stopper med at virke er netop
kendetegnet ved et DOS angreb. I dette tilfæde er målet browseren.

> Da Windows ikke kan håndtere swapping særligt godt vil det på denne
> platform skabe en situation hvor systemet stopper med at virke. Hvis
> Windows systemet selv får hukommelses fejl vil det desuden crashe
> maskinen.

Lynx under Windows? Det vil jeg se før jeg tror det.

>> En buffer overrun med tilfældige data får et program til at crashe. En
>> buffer overrun med velvalgte data giver adgang til maskinen.
>>
>> Første skridt er at få browseren til at crashe. Næste skridt er så at
>> analysere stack og registre på crash-tidspunktet i en debugger, og
>> dernæst kan man så konstruere de velvalgte data der giver adgang til
>> maskinen.
>
> Den funktion der har en situation den ikke tager højde for er en
> rekursiv funktion, der ikke håndterer at en situation kan skabes hvor
> den bliver udført så mange gange som den gør og den fejler så på et
> tidspunkt med en memory fejl når den forsøger at en push til stack
> memory området. Dette er ikke de samme some buffer overflow:

Mig bekendt fortalte artiklen ikke noget om hvilken funktion i
firefox det er der crasher. Og det var ikke den fejl der resulterede
i out of memory, det var lynx-fejlen ovenfor.

Firefox crashede blot, hvilket kan tyde på at noget er blevet
overskrevet, og en retur-adresse på stacken der bliver overskrevet
er en meget effektiv måde at crashe et program.

Derfor begynder folk at snakke om potentielle sikkerhedshuller i
den forbindelse.

> Du er vist blevet lidt for forvent med alle de stack overflows, som har
> ramt især Microsoft programmer, pga. dårlig sikkerheds programmering og
> tror du er blevet den store specialist, men programmering er en hel del
> mere kompliceret end hvad man høre om i pressen.

Jeg bekymrer mig ikke om Microsofts sikkerhedsfejl, de resulterer
højst i lidt spam, hvoraf spamassassin tager det meste.

> Så på ingen platform er der tale om andet end en bug og det høre ikke
> til i en sikkerheds diskussions gruppe.

Det vides ikke før programmørerne har haft tid til at kigge koden
igennem. Sålænge de ikke siger med sikkerhed at de nævnte fejl ikke
kan resultere i et exploit, er muligheden åben. Og derfor bliver det
betragtet som et sikkerhedshul, og sendt til diverse sikkerheds-
relaterede mailinglister.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

On Sun, 2004-10-24 at 17:08 +0000, Kent Friis wrote:
og Jens skrev omtrent det samme i et andet indlæg med andre ord:

> Og at målet for angrebet terminerer/stopper med at virke er netop
> kendetegnet ved et DOS angreb. I dette tilfæde er målet browseren.

Interessant, to formentlig uafhængige personer vælger begge at svare på
en del af mit indlæg med den samme snak om DoS, det er bare lidt
underligt at den del af mit indlæg ikke på nogen måde giver udtryk for
en modsat holdning, det er nok bare mig der er gammel dags og syndes det
er lidt spild af tid at være uenig for uenighedens skyld, i stedet for
at bruge krudtet på at være uenig der hvor der er en uenighed og ikke
bare en mindre forskel i valg af ord.

> Lynx under Windows? Det vil jeg se før jeg tror det.

http://www.fdisk.com/doslynx/lynxport.htm

> Mig bekendt fortalte artiklen ikke noget om hvilken funktion i
> firefox det er der crasher. Og det var ikke den fejl der resulterede
> i out of memory, det var lynx-fejlen ovenfor.

Her bruger jeg min tid på at undersøge tingende så jeg kan skrive et
detaljeret indlæg og hvad får jeg ud af det, absolut intet for du vælger
totalt at ignorer vært evigt eneste ord jeg har skrevet, suk, utak er
verdens løn.

---

Den Mon, 25 Oct 2004 04:01:09 +0200 skrev Steen Eugen Poulsen:
> On Sun, 2004-10-24 at 17:08 +0000, Kent Friis wrote:
> og Jens skrev omtrent det samme i et andet indlæg med andre ord:
>
>> Lynx under Windows? Det vil jeg se før jeg tror det.
>
> http://www.fdisk.com/doslynx/lynxport.htm

Jeg er ikke i tvivl om at det er muligt. Men før at det bliver et
sikkerhedshul, kræver det jo *brugere*

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

On Tue, 19 Oct 2004 17:40:49 +0200, Alex Holst <a@mongers.org> wrote:

> I skrivende stund har Firefox ikke nogle specifikke problemer.

http://www.mozilla.org/projects/security/known-vulnerabilities.html

-A
--
http://www.hojmark.org/

---

I dk.edb.sikkerhed, skrev Asbjorn Hojmark:
> On Tue, 19 Oct 2004 17:40:49 +0200, Alex Holst <a@mongers.org> wrote:
>
> > I skrivende stund har Firefox ikke nogle specifikke problemer.
>
> http://www.mozilla.org/projects/security/known-vulnerabilities.html

Kiggede du på siden inden du postede linket?
Det er liste over sikkerhedsproblemer der _har været_ i Firefox incl
dato for hvornår de er fixed.

Jesper

--
../Jesper Krogh, jesper@krogh.cc
Jabber ID: jesper@jabbernet.dk

---

On Sun, 21 Nov 2004 17:12:37 +0000 (UTC), Jesper Krogh
<jesper@krogh.cc> wrote:

>>> I skrivende stund har Firefox ikke nogle specifikke problemer.

>> http://www.mozilla.org/projects/security/known-vulnerabilities.html

> Kiggede du på siden inden du postede linket?

Ja.

> Det er liste over sikkerhedsproblemer der _har været_ i Firefox incl
> dato for hvornår de er fixed.

Den er dog interessant i forhold til "Der er så mange sikkerheds-bugs
i IE"-argumentet.

-A
--
http://www.hojmark.org/