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
(Remote DOS attack) 0day buffer overflow vulnerability reveal #629
Comments
In future, it may be wise to message the maintainer privately first and let them confirm the issue and give them the standard period before releasing either way. I've messaged the maintainer on IRC, waiting for an update. |
Will memcached users be afforded the same consideration by attackers? |
I applaude Icejl here because now people who don't want to get DOSed can disable/remove the buggy memcached version (or fix it and recompile; since it's such a small change anyway). Without that information they may otherwise run vulnerable code, so I am 100% in support of Icejl and completely against thesamesam's suggestion to be silent. "Standard period" means unknown silence and no fixes in that time, so it is a misnomer. |
I didn't come up with the idea of responsible disclosure, I was just suggesting. I don't intend to debate on the merits of it - that's for the wider community to decide. Just letting the OP know that it's a thing. This happens in a lot of places, and I'm not the person to take it out on if you disagree with it. |
Locking this off-topic discussion. |
1.6.2 released with fix: https://github.com/memcached/memcached/wiki/ReleaseNotes162 and fwiw, I've been responsive to security reports (or even report them myself) and give credit happily when due for over ten years. Don't waste my good will, please. |
Hi, Memcached team,
Recently, I revealed a buffer overflow vulnerability which may cause DOS attack. The exploit details can be found as following.
Affect Version
memcached-1.6.0
memcached-1.6.1
Root cause
file location: memcached.c:6156-6187
Code Audit
in line 6179, since there is no mechanism to verify the parameter's length, in this case, the length of "extlen" when calling memcpy function, It will cause buffer overflow if large value assigned to the extlen variable.
POC
for the POC snippet, first, if I assign a large value to the variable extlen, on the other hand, in order to bypass the validation of data packet which sent in following code snippet,
6156 if (c->rbytes < keylen + extlen + sizeof(c->binary_header))
we can construct a very large data packet and send it to the server running memcached 1.6.0 or 1.6.1 anonymously. After that, the program will crash because of the issue mentioned above.
Note: Please confirm this issue ASAP. Besides, just letting you know, I am gonna submit this issue to CVE mitre.
Please let me if you have any questions.
Sincerely,
Icejl
The text was updated successfully, but these errors were encountered: