- NLNOG - NLNOG

http://www.webwereld.nl/nieuws/16281.phtml
by N.Kolstein＠Planettechnologies.nl 19 Sep '03

19 Sep '03

Hi, Volgens dit bericht op webwereld zouden er problemen zijn met Planet en Het Net ADSL abo's met het bereiken van de KVK-site. Nu moet ik allereerst nog de juiste persoon binnen KVK vinden die enig clue heeft en weet wat het probleem nu precies is, maar ik wilde hier op NLNOG even peilen of er meer KPN ADSL ISP's zijn die van klanten problemen doorkrijgen mbt. de KvK site. En wellicht is er al ergens een oplossing bekend. Mijn vermoeden gaat uit dat er iets in het SSL-stuk van KvK b0rken is, maar dat moet nog wel even gechecked worden. Alvast bedankt voor de hulp.. Groet, Nils Kolstein KPN Planet Technologies - AS8737 n.kolstein at planettechnologies.nl

2 1

http://www.webwereld.nl/nieuws/16281.phtml
by erik＠is.nl 19 Sep '03

19 Sep '03

/hmm met kvk nog geen problemen gezien.. Heb je een specifieke URL die verkeerd gaat ? Wel issue's met www.rabobank.nl en www.dnb.nl bij ons vandaan.. Dat lijkt een UUnet/KPN netwerk issue .. Met vriendelijke groeten, Erik Bais -------- I S - I N T E R N E D - S E R V I C E S - B V -------- domeinregistratie - webhosting - colocating - dedicated servers www.is.nl - info at is.nl - T: 0299-476185 Gorslaan 18 - 1441 RG - Purmerend --------------------------------------------------------------- > -----Original Message----- > From: Nils Kolstein [mailto:N.Kolstein at Planettechnologies.nl] > Sent: Friday, September 19, 2003 11:49 AM > To: nlnog at nlnog.net > Subject: [Nlnog] http://www.webwereld.nl/nieuws/16281.phtml > > > Hi, > > Volgens dit bericht op webwereld zouden er problemen zijn met > Planet en > Het Net ADSL abo's met het bereiken van de KVK-site. > Nu moet ik allereerst nog de juiste persoon binnen KVK vinden die enig > clue heeft en weet wat het probleem nu precies is, maar ik > wilde hier op > NLNOG even peilen of er meer KPN ADSL ISP's zijn die van klanten > problemen doorkrijgen mbt. de KvK site. En wellicht is er al > ergens een > oplossing bekend. > Mijn vermoeden gaat uit dat er iets in het SSL-stuk van KvK b0rken is, > maar dat moet nog wel even gechecked worden. > > Alvast bedankt voor de hulp.. > > Groet, > > Nils Kolstein > KPN Planet Technologies - AS8737 > n.kolstein at planettechnologies.nl > _______________________________________________ > NLNOG mailing list > NLNOG at nlnog.net > http://mailman.nlnog.net/mailman/listinfo/nlnog > >

2 1

Extreme EAPS fun :)
by nils.swart＠attorn.nl 18 Sep '03

18 Sep '03

Allemaal, Vanochtend kreeg Multikabel een mooi mailtje van de AMSIX met de vraag waarom wij port security aan het triggeren waren. Welnu het volgende verhaal is wellicht interessant, en kan een mailtje van de AMS-IX schelen: Recept: Men neme een viertal Extreme Networks Alpine switches en sluiten die in een vierkant aan. EAPS zorgt voor sub-second failover van links. Op een van de vier switches neme men een aansluiting op ons aller AMS-IX lan, alwaar men port security in de vorm van mac address counts ingesteld heeft. Bij de voorbereiding voor een firmware upgrade worden gedurende business hours de nieuwste versies ingeladen op de secondary slot van de switches. Gedurende deze TFTP file transfer _vergeet_ de switch te luisteren naar EAPS updates. Resultaat: een EAPS ring instabiliteit & een case bij Extreme. Nu is alleen nog even onduidelijk waarom er vervolgens mac adressen die gelearnd zijn uit poort A ook weer terug gaan naar poort A. Maar een ding is zeker: Bij het upgraden/transferen van firmware in uw EAPS netwerk, gaarne de poort met de AMS-IX dicht zetten. Demon & BIT: u bent gewaarschuwd :) Greets, Nils Swart nils.swart at attorn.nl

12 35

NIET nog es!
by erik＠is.nl 18 Sep '03

18 Sep '03

FF gechecked welke versie van SSH die Extreme dozen van ons gebruiken .. Reply van Extreme Support hierover : <begin snip> ExtremeWare does not use OpenSSH's implementation ofthe SSH protocol. All references in the link were related to the this specific implementation, and do not apply to ExtremeWare. Using an access-list to block ssh traffic will block the packets in hardware, even before they hit the CPU. The other possibility is that they use access-profiles, where the packets are dropped by the CPU, before any buffers are allocated for ssh connections. <end snip> Met vriendelijke groeten, Erik Bais -------- I S - I N T E R N E D - S E R V I C E S - B V -------- domeinregistratie - webhosting - colocating - dedicated servers www.is.nl - info at is.nl - T: 0299-476185 Gorslaan 18 - 1441 RG - Purmerend ---------------------------------------------------------------

1 0

Ehh Alex ?
by pim＠bit.nl 18 Sep '03

18 Sep '03

On Thu, Sep 18, 2003 at 09:22:42AM +0200, Arjan wrote: | Wattisdit? Het is een kleine fuckup mijnerzijds. Bij het upgraden van sendmail van 8.12.8 naar 8.12.10 vanmorgen bleek de queuerunner nog niet te draaien (of heeft nooit gedraaid), dus zijn mails lokaal op de mailserver niet uitgestuurd tot nu. Queue is leeg inmiddels, mail is weg. Sorry voor het ongemak! groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________

1 0

[sabri@bit.nl: [olympus] [pim.van.stam@nlip.nl:[Security-l] [Fwd: [o-IRT-o] sendmail feest]]]
by jeroen＠unfix.org 17 Sep '03

17 Sep '03

-----BEGIN PGP SIGNED MESSAGE----- Arjan wrote: > On Wed, 17 Sep 2003 at 16:19 +0200, Sabri Berisha wrote: > > > There seems to be a remotely exploitable vulnerability in Sendmail up to > > and including the latest version, 8.12.9. The problem lies in prescan() > > function, but is not related to previous issues with this code. > > Ik geloof dat het winnende woord hier "sendmail" is. Oude code, hoe open de source ook is kan ook vulnerable zijn want je kan gewoon niet alles auditen blijkt maar weer. Beste voorbeelden zijn phpbb en phpnuke en die buggen niet eens op van die creatieve dingen als met deze buffertjes en misrekeningen met pointertjes. Ik vraag me af wanneer de eerste combowormen uitkomen die Windows en *nix machientjes kunnen infecten, vast crea. En let op, voor OpenSSH zijn er 2 patches! 3.7.1p1 is de goeie momenteel, rest is lek... Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2hx8CmqKFIzPnwjEQLDgQCfc/wYR/UpfGlkNdSAV4g2BC4Kcp4An3dO iGX6c1otkU5fvg4+4jXtAU/M =PrzT -----END PGP SIGNATURE-----

1 0

[sabri@bit.nl: [olympus] [pim.van.stam@nlip.nl: [Security-l] [Fwd: [o-IRT-o] sendmail feest]]]
by sabri＠cluecentral.net 17 Sep '03

17 Sep '03

---------- Forwarded message ---------- Date: Wed, 17 Sep 2003 11:19:46 +0200 (CEST) From: Michal Zalewski <lcamtuf(a)dione.ids.pl> To: bugtraq at securityfocus.com, vulnwatch at securityfocus.com, full-disclosure at netsys.com Subject: [Full-Disclosure] Sendmail 8.12.9 prescan bug (a new one) [CAN-2003-0694] Hello lists, -------- Overview -------- There seems to be a remotely exploitable vulnerability in Sendmail up to and including the latest version, 8.12.9. The problem lies in prescan() function, but is not related to previous issues with this code. The primary attack vector is an indirect invocation via parseaddr(), although other routes are possible. Heap or stack structures, depending on the calling location, can be overwritten due to the ability to go past end of the input buffer in strtok()-alike routines. This is an early release, thanks to my sheer stupidity. -------------- Attack details -------------- Local exploitation on little endian Linux is confirmed to be trivial via recipient.c and sendtolist(), with a pointer overwrite leading to a neat case of free() on user-supplied data, i.e.: eip = 0x40178ae2 edx = 0x41414141 esi = 0x61616161 SEGV in chunk_free (ar_ptr=0x4022a160, p=0x81337e0) at malloc.c:3242 0x40178ae2 <chunk_free+486>: mov %esi,0xc(%edx) 0x40178ae5 <chunk_free+489>: mov %edx,0x8(%esi) Remote attack is believed to be possible. ---------------- Workaround / fix ---------------- Vendor was notified, and released an early patch attached below. There are no known workarounds. Index: parseaddr.c =================================================================== RCS file: /cvs/src/gnu/usr.sbin/sendmail/sendmail/parseaddr.c,v retrieving revision 1.16 diff -u -r1.16 parseaddr.c --- parseaddr.c 29 Mar 2003 19:44:01 -0000 1.16 +++ parseaddr.c 16 Sep 2003 17:37:26 -0000 @@ -700,7 +700,11 @@ addr[MAXNAME] = '\0'; returnnull: if (delimptr != NULL) + { + if (p > addr) + p--; *delimptr = p; + } CurEnv->e_to = saveto; return NULL; } -- ------------------------- bash$ :(){ :|:&};: -- Michal Zalewski * [http://lcamtuf.coredump.cx] Did you know that clones never use mirrors? --------------------------- 2003-09-16 21:18 -- -- Met vriendelijke groet, __________________ Sabri Berisha /\ ___/ SAB666-RIPE /- \ _/ Business Internet Trends BV http://www.bit.nl/~sabri /--- \/ __________________ _______________________________________________ Olympus mailing list ----- End forwarded message ----- -- Met vriendelijke groet, __________________ Sabri Berisha /\ ___/ SAB666-RIPE /- \ _/ Business Internet Trends BV http://www.bit.nl/~sabri /--- \/ __________________

1 0

Cisco?
by erik＠is.nl 09 Sep '03

09 Sep '03

> Dat Junipers het _wel_ in hardware doen dus. De forwarding wordt in hw gedaan. klopt. Nadat de Protocols de Routing table hebben geparsed, een subset wordt dan in de forwarding table gezet en deze is dan in de PFE gezet. Update's etc.. worden door de RE in de PFE gezet.. niks hardware .. Geen RE = geen nieuwe beslissingen meer.. Dat lijkt mij net zoveel in hw als in de Extreme's. Als je een crash van een SMM zouden hebben, zou de hardware nogsteeds alles blijven forwarden. ( been there, seen it ;-/ ) Alle BGP Peers zo dood als wat, maar de hardware bleef vrolijk doorlopen.. en aangezien de routes door een andere switch nog steeds ge-adverteerd werden, kwam het verkeer gewoon via een andere kant binnen, maar ging het nog steeds via de 'oude' weg naar buiten, bij gebrek aan ASIC's update. Ik heb in Mountaint View op de 5 day Juniper training de trainer een RE uit een M40 zien halen, waardoor er niet meer dan 2 packets verloren gingen.. impressive .. en zeker zoveel toen hij die RE er weer in stak.. > Vind je? Ik kan me het debacle met Scarlet nog goed herinneren, waar > Extreme uiteindelijk een Juniper heeft neerzet omdat de Extreme die ze > hadden aangeboden niet deed wat beloofd was. Dat is krap aan een jaar > geleden. Het debacle met Scarlet ken ik vrij goed.. De firmware met de oplossing van het probleem was op dat moment al beschikbaar, maar door politiek bij hun intern en dingen in hun config wat niet als best-practice gezien wordt en geen standaard change policy maar een 'ad-hoc laten we wat wijzigen vandaag' policy is toen door Extreme besloten tijdelijk een Juniper M5 in te zetten. De oplossing in de interim-release is later ook in de main-stream code meegenomen. Sterker nog ... De Juniper M5 heb ik er toen zelf in opdracht van Extreme neergezet en ge-installeerd.. Met vriendelijke groeten, Erik Bais -------- I S - I N T E R N E D - S E R V I C E S - B V -------- domeinregistratie - webhosting - colocating - dedicated servers www.is.nl - info at is.nl - T: 0299-476185 Gorslaan 18 - 1441 RG - Purmerend ---------------------------------------------------------------

12 32

Cisco?
by erik＠is.nl 09 Sep '03

09 Sep '03

I would be more than interested in the amount of new destinations the different vendors can sustain with their hardware. I've seen the tests like this in the Juniper poc lab and I'm very keep to see something like this on the Alpine's / BD's. I've been told by Luuk from Extreme that he would like to see some tests like this as well and if we needed some kit for the test he would see where he could help out. ( alpine / BD / ixia in the lab that sort of things..) It might also be a good moment to ask them how they handle this in hardware, instead of wild guessing how it's done. Met vriendelijke groeten, Erik Bais -------- I S - I N T E R N E D - S E R V I C E S - B V -------- domeinregistratie - webhosting - colocating - dedicated servers www.is.nl - info at is.nl - T: 0299-476185 Gorslaan 18 - 1441 RG - Purmerend ---------------------------------------------------------------

3 2

Cisco?
by alex＠bit.nl 09 Sep '03

09 Sep '03

Hi, http://noc.bit.nl/vendors/ Ik stel voor dat we weer wat gaan borrelen op het moment dat Cisco van z'n absolute meerderheid af is. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE

5 5