[back] [Raw Mail Archive]
While writing the syslog-protocol draft, I made the decision to very tightly specify everything - maybe too tightly, as some feel (for a discussion, see syslog-protocol issue 13).
I am outlining my basic idea behind this in-depth description here on this page, so that I can also update it with additonal pointers. It all started with a mail reply, from which I have taken the important content regarding this issue. I (Rainer Gerhards) started this page here on 2004-02-24 (just so that you have a sense of time ;)).
This is a (very) lighly edited version orginal stated in http://www.syslog.cc/ietf/autoarc/msg01152.html. I removed everything that is not directly related to the philosophy I try to convey. I tried hard to conserve all typos for the fun of it ;) While reading, keep in mind the mail was addressed to the memebers of the IETF syslog-sec WG mailing list.
Please let me elaborate a little on why the draft is sometimes very specific and lenghty.
I am working in the IT security space, as probably many of you do. If I look at past and recent vulnerabilities, there are at least two classes: one is "simple" program bugs and the other one is interoperability weaknesses/differences. Let's dig down on the second class: Many attacks are successful because the underlaying spec leave (too) much room for interpretation. A good example is malware transported via email as vector. To avoid misunderstanding, I am NOT bashing on the mail-related RFCs - they are well thought-out and have prooven to be big drivers behind the Internet. However, they were created in a time where the Internet was a much friendlier space than it is today. In these days, everybody was interested in getting things going and if something went wrong, then it was an unintentional bug, not an intentional attack. Consequently, it paid to try to understand what the other peer meant and try to correct it so that things work.
Nowadays, I need to sadly admit, a lot of effort is put into trying to *break* things. Wrack systems. Spread malware. And the like. If you receive a malformed packet today, chances are greater that it is intentionally malformed than they are that it is a simple program bug.
Trying to make things work with such malformed packets can actually cause more trouble than it is worth. A good example was the email malware vector recently discussed on e.g. the full disclosure mailing list. As people pointed out there, different programs have different ways of handling improperly formed MIME message. Each implementation tries its best in guessing what the sender might have meant and work on that assumption. Unfortunately, the assumptions are different from vendor to vendor and program to program (some change even between program versions). So you do not have a consistent behaviour. Malware authors can use this to generate malformed MIME encodings which include executable content, that the ultimate recipient (MUA) actually interprets as executable. But they may do it in a way that the malware-scanning MTA interprets differently. Thus, it does not think the message contains executable code and does not scan it (it may not even see a file at all). The end result is that malware is delivered to the MUA (and executed there) because of different interpretations of a malformed MIME encoding - different implementations implemented in the MTA and MUA.
Keep in mind that this is not a hypothetical theory, but a practical sample that has been discussed (and to be best of my knowledge, exploited!) in the wild.
What does me lead this to? I am of the very strong opinion, that in today's Internet, a specification must very precisely define what it considers correct and what incorrect. And I think it should also provide detailled instructions on what should happen to malformed packets. So the goal should be that messages that are malformed in whatever way should not be processed or at least treated in a consistent way. Of course, even with such a detailled spec, not everybody will actually implement it in this way, but chances are much greater that most will do. Plus, sombody emiting invalidly formatted messages will quickly be punished by not being understood by their peers. In today's highly connected world, this should probably put enough pressure on the misbehaving implementation to change - at least I hope so.
Before somebody else raises hands ... yes, I know I am in quite some contrast to Jon Postel 's "Be liberal in what you accept, and conservative in what you send.". I don't claim I am wiser than Jon was. I am in no way. In fact, there are many people on this list a lot smarter than me (thanks for all their comments and letting me learn). But I have to admit that I consider Jon's wisdom as wisdom from another time (where the Internet was a friendly place).
If I look at todays highly "brutal" Internet, is it really a good idea to assume that everybody is friendly and you try to help them out if they made a little mistake? Or is it probably better to think "if this guy sends me invalid parameters, I'll better tell him to do it right or go away (as he is probably trying to probe me for weaknesses)". I have to admit, I think the later is the case.
While conducting some search for actual cases, I found this thread here:
http://www.netsys.com/ietf/1999/5245.html
It is stated there:
Almost every time I see the "be liberal..." quote, the context in which it is said it dropped. I belive the context is MORE IMPORTANT than the quoted text. The context is achieving interoperability. Interoperability is more important than any other thing.
This is a 1999 statement, where the Internet was much more healthier than it is today (but it began to diminish...). I think a very good summary of the spirit behind Jon's quote is:
"Interoperability is more important than any other thing."
This is what I am questioning today. I think in today's Internet, security is the most important thing and then comes interop ... and then the rest. So I think it is a valid point to requires stricter adherance to standards than in the past - which in turn requires the standards to be more precise in what is valid and what not.
Please keep in mind that a very detailled spec may indeed look like a solution. But please also keep in mind that it also means the spec has more pages and it eventually is easier to overlook something really important. A detailled spec eventually tends to be more complex, which may also result in a higher probability of mis-interpretation (and thus be bug source in itself).
I asked a few mailing lists for advise, unfotunately there are few responses yet. Here, I am tracking those that were publically posted. I receive private responses as well, but I will only post them after permission from their respective senders. So the list is not complete. I am still waiting for responses, so this list is in no way finished.
This page last updated: Tue Sep 25 13:32:30 2007.
For content issues, contact rgerhards-at-adiscon.com - for legal issues, please contact Adiscon who is the legal owner and publisher of this web site.
Visit our topic pages for practical information on syslog.
Raw Mail Archive: [threaded] [by date] [search]