> I'm with you on this. I suppose it makes ASN.1 seem more likely and > perhaps harder to resist if faced with it, but how many buffer overflows, > etc, are because of problems with string handling ? Unless we are all > using a "safe" language like Java, where you'd just write serialise > methods for the log objects, it just seems like we're asking for trouble. > > I suppose there have been similar problems with ASN.1 and SNMP so if > we were to avoid strings on the grounds of security, so too we should > try and avoid ASN.1 (which is less than trivial to parse or generate.) I can't resist un-lurking to add here: when ppl say 'ASN.1', they seem to mean the accompanying serialisation standard, BER. AFAIK you can have a secure ASN.1 if you don't use BER - the 'A' is for 'Abstract' & ASN.1 doesn't specify anything that goes on the wire. The fundamental prob w/ BER security IMO is the indefinite length encoding, which can apply to many other data types besides string. Even without this problem, from one who has implemented this very rococo standard, like most of OSI, ASN1's one of those great universal pickles that ain't worth the pain. There was talk here some months ago abt how regexp parsing would add unacceptable overhead - check out ASN1 & you find a kindred overhead in your serialisation. -- Rich Fuchs rbfat_private (*nix system programmer, RLG) _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Tue Dec 24 2002 - 01:35:59 PST