QMClient potential weakness, security/hang issue

[Diccon]

Thought this was worth pointing out. It's very unusual circumstance,
but it is possible, which is all that matters for security.

If, for what ever reason, the qmclient process using xinetd is subject
to malicious attempts to open the socket and use it then it has a very
high risk of chewing up resources until there are no more. Ultimately
causing a machine hang.

The circumstance we've come across it are unusual but still point out
the risks.
A machine has an external pipe through from the internet to it's local
port 4243. This appeared to the world as port 80 on a public IP
address. This was a work around for reasons related to another network
blocking outgoing 4243. Understandably the external address got a lot
of automated cracks and attacks checking port 80 for admin interfaces
or website they can attack, nothing unusual and very annoying. These
attempts were presuming 80 was a web server, confusing the QMClient
service it left a session open for each attack. Over a period of time
the server had all it's resources chewed up by qmclient processes that
do not die. The machine cried many out of memory errors and hung.
Basically a standard fork bomb style crash, as it has to run qmclient
as root it ends up killing the machine.

I have come across qmclient resource hogging by multiple qmclient
instances before during the Java and PHP API development, but
dismissed those as bugs in my attempts to develop the API's. I never
envisage "trying" to break the qmclient service, and normal use of the
protocol does not cause this issue.

Martin, I will look into creating a test app to recreate this issue,
which I will share. Which you can run against your latest commercial
QM.
I will then look into how to protect against it and where the
responsibility lies. With xinetd or with qmclient itself. I suggest
you do the same.

Even if on a closed LAN this represents an easy way to crash a QM
server.

This is running on the 2.6-6 fork of OpenQM, if you have fixed it that
is fine and this warning can be ignored. I will work on Scarlet and
see how to build in protection regardless.

Regards
-Diccon

[Martin Phillips]

Hi Diccon,

Thanks for the details on this problem.

The solution is for QMClient to be more sensitive to the incoming data in
the initial packet. As things stand, it expects the received data to be a
properly formed login packet, including a byte count. I suspect that what is
happening is that the position in which we expect to find this count is
occupied by text but gets interpretted as a (massive) count that causes the
memory problems.

We have modified the incoming end of a QMClient connection to sense that the
byte count is unreasonably large for a login packet and to disconnect. The
code already disconnected for invalid packet types.

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200

[Diccon]

This might be overstated. Tests show i can cause 8 QM processes to
chew up 100% of the CPU, but can not cause memory bomb as previously
suggested.

It's still worth investigating though.

-diccon

[Diccon]

Thanks Martin. I will look at implementing a similar protection.
-Diccon

On Sep 11, 3:53 pm, "Martin Phillips" <martinphill...@ladybridge.com>
wrote: