Re: I want my MOM

On Mon, 24 Oct 2005 13:51:50 +0900
Brian McCallister <brianm@xxxxxxxxxx> wrote:

> Feedback is much appreciated!
>
> On Oct 23, 2005, at 9:17 PM, Zed A. Shaw wrote:
<snip>
> > 5) Require that the header MUST have the content-length
> > settings. This
> > is again to make sure that requests which are too large are always
> > booted. Making this optional just leaves open an attack where you
> > again slam the server with never ending data until it dies. This
> > also makes it very clear how the content is always sent and leaves
> > nothing open for debate.
>
> I disagree with this -- you can bring down a naive server
> implementation with or without this change -- just slam data into
> whatever buffer is accumulating it until it croaks -- almost every
> (I would say every but I don't know for a fact) JMS implementation
> available does a full read for messages which are not of type Stream
> (which is an option for huge messages).
>
You can bring down any server (especially a niave one), it's just a
hell of a lot harder if the server is able to always know
received data sizes and to boot clients if they are over the
allowed sizes.

Normally these specifications are not designed to prevent
attacks totally (can't be done) but rather to make it easier for a
server to have a reason to boot bad clients. Additionally, it lets the
server properly size receive resources so that it can scale
appropriately. If your server knows the size of all data coming in
then it's a piece of cake to meet service needs by setting input/output
sizes appropriately.

Another thing a pre-sized protocol does is make it much harder to have
buffer overflows. Since all buffers always have a size, and the
protocol always has a size for each read, then you don't get buffer
overflows (as much).

In other words, yes morons will always write bad clients/servers, and
yes other people write their implementations with line-endings, but that
sure as hell don't make line-ended protocols right. As a bit of
history, line-ended protocols were almost exclusively the domain of
UNIX systems since the BSD sockets guys convinced everyone that "a
socket is just a file". This led people to think, "Oh, then I'll just
read lines from it like a file." Problem is, how many files do you
open up where there's a bad guy on the other end messing with your
file's data using a dirty connection? This is why "sockets are files"
and line-ended protocols are super bad. Sockets are not files, be safe.

My best analogy is it's the difference between wearing a condom
with your wife and going to a glory hole. Uh, ok, that's a *really* bad
analogy. I'll stop right there. :-)

But, like I said previously, saying that your protocol is telnet
accessible is just a super bad idea. The only people who ever need
telnet access are developers (who should be able to write a client), or
attackers (who should not be given any more help than they already
have).

Anyway, that's my argument. Let me know if it goes anywhere with the
STOMP folks.

<snip>
> > 7) State that ":" is not a valid header. This means that they
> > can't send empty headers.
>
> What is wrong with an empty header? It wastes bytes, but then so
> does a long message.
>
Empty headers are fine, I meant the null header (see below).

> :
>
> is bizarre, and wastes a little bit of space, but doesn't *hurt* the
> protocol. In a defensive server, it would be fair to consider it a
> potential attack and consider dropping the client. I am not sure
> specifying this behavior adds anything to the spec except "oh yeah,
> make sure of this" for implementors.
>
It's simply a suggestion to close a potential loop-hole.

Thanks for listening. Let me know what comes of it. I'm basically
basing a kind of little messaging system on STOMP with these changes.

Zed A. Shaw
http://www.zedshaw.com/


.

Relevant Pages

  • Re: SBS 2003 - VPN - IPX Configuration
    ... Did you add that protocol to the server and the clients? ... > We have an older client/server product that requires the protocol. ... fine on any windows LAN with ipx/spx installed (No Novell Server). ... >> IPX portion of the VPN clients connection. ...
    (microsoft.public.backoffice.smallbiz2000)
  • client -server interaction over XML supporting multiple protocols
    ... I am in process of developing a Server in C++ supporting multiple ... server doesnot know in advance which client is using what protocol. ... client1 is communicating over protocol TCP to access X ... is able to handle multiple clients at the same time over TCP /IP. ...
    (comp.lang.cpp)
  • Re: Server/Clients system
    ... What I want to do is have a server that resides ... Then these 2 clients will ask the server for another file ... reimplementing as much of the protocol as you desire. ... to make many transfers every minute, can BitTorrent do this? ...
    (comp.lang.perl.misc)
  • Re: IIS 5.0 Accept Header Bug: Any Workarounds?
    ... The Accept header is in the HTTP specification for a good reason. ... Hacking the web server to accept broken web clients, ... It is possible to hack IIS to munge/remove the incoming Accept header so ...
    (microsoft.public.inetserver.iis)
  • Threading issue
    ... I've written a component which will be used by client and server ... each structure is serialized contains a header ... i have 10 clients connect to the server and they ... the problem i am having occurs in the receiving section of ...
    (microsoft.public.dotnet.framework)
Loading