-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error logging found in stream to client (security issue) #647
Comments
I guess it should be treated carefully due to a security issue. Keep in touch if you have any update. |
@edwin-oetelaar The MQTT-SPY that does out-of-memory is it running on the same host as the Mosquitto server ? Said otherwise, is it possible that Mosquitto had memory allocation issue due to low free memory ? |
About websockets enabled : yes listener 9001 |
Which version of libwebsockets are you using? Is that the full listener/port configuration? |
I am running this : https://github.com/toke/docker-mosquitto a docker image without modifications. The config is here :
I really have no idea what version of libwebsockets it contains. |
did you configured with bridge? is there any possibilities that some client encountered a duplicate close after it's context has been freed? could you call assert(0) once COMPAT_CLOSE() with sockfd =1 in the code so that we can find the answer from the core file asap since this is a series danger? |
That's helpful, it means it is the version of libwebsockets from Debian Jessie which I can get directly. |
Some more questions for you - are you actually using websockets clients, and how many clients do you have connected? |
I have no websockets connected. |
If you do have websockets clients, I'm concerned we might be seeing a problem in libwebsockets 1.2, which is now ancient and never worked properly for us anyway. |
I have found that a badly behaving client (mqtt spy running out of memory)
can make mosquito version 1.4.14 close socket(0) somehow.
(running linux)
This means that a newly connection client gets socket with number 0 or 1 and so also gets stdout/stderr intermixed with the normal protocol.
This looks like : (wireshark grap)
.p...#..'...#.......6...;......e....sO?z........................V
...Kyd..x....8S......(l...p....."@<....w..Z......e...o.....M.7...'._..g..........................1512729645: Socket error on client , disconnecting.
1512729645: New connection from 172.17.0.1 on port 1883.
1512729645: Client bd-00:1c:c0:b1:de:50 disconnected.
1512729645: New client connected from 172.17.0.1 as bd-00:1c:c0:b1:de:50 (c0, k10, u'bierserver').
1512729793: Socket error on client oetelaar_mqttspy123, disconnecting.
1512729793: New connection from 172.17.0.1 on port 1883.
1512729793: New client connected from 172.17.0.1 as oetelaar_mqttspy123 (c1, k60).
1512729804: Client bd-00:1c:c0:b1:de:50 has exceeded timeout, disconnecting.
This prevents the client from connecting, but it is a symptom of something far more serious.
I will investigate, but maybe some else can look into it too.
Best regards,
Edwin van den Oetelaar
Update : after looking more in detail, it looks like close(1) is performed, stderr ends up in stream
Update2 : I am not sure if fd=0 or fd=1 or something else is writing to the socket.
It might also be that the log-file is closed (from out of disk space) and the logger writes into the known fd, which is now re-used as a new socket-fd, which causes the logging to end up in the socket-stream.
I have come to this conclusion because the redirected stdout contains full logging, including the data that was found in the stream.
Update3: I can not trigger the problem, however I have seen it in the wild at least 4 times, I will investigate more
Update4: I have compiled 1.4.14 on linux ubuntu 14.04 and tested and can not trigger the problem, the setup with the problem is a docker image https://hub.docker.com/r/toke/mosquitto/
Update 5: 25/12/2017 It happened again (wireshark dump)
then a retry, see protocol version changed:
This one is even more interesting, the connection happens syn/ack but the server does not wait.. it just dumps data to the client before client can send anything, it then handles some of the protocol but dumps the info in the stream again.
This continues a while
and then after about 15 failed connects it works
It ran for days without problems, but then a client MQTT-SPY v1.0 ran out of memory (could be completely unrelated)
The text was updated successfully, but these errors were encountered: