Skip to content
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

Closed
Icejl opened this issue Mar 23, 2020 · 6 comments
Closed

(Remote DOS attack) 0day buffer overflow vulnerability reveal #629

Icejl opened this issue Mar 23, 2020 · 6 comments

Comments

@Icejl
Copy link

@Icejl Icejl commented Mar 23, 2020

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

image

Code Audit

6178   char extbuf[sizeof(c->binary_header) + BIN_MAX_EXTLEN];
6179   memcpy(extbuf + sizeof(c->binary_header), c->rcurr + sizeof(c->binary_header), **extlen**);

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

0x80 0x01 [0x00 0x00] keylen

[0x30] extlen 0x00 0x00 x00

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

@Icejl Icejl changed the title (DOS attack) 0day buffer overflow vulnerability reveal (Remote DOS attack) 0day buffer overflow vulnerability reveal Mar 23, 2020
@thesamesam
Copy link

@thesamesam thesamesam commented Mar 23, 2020

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.

@Crest
Copy link

@Crest Crest commented Mar 23, 2020

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.

Will memcached users be afforded the same consideration by attackers?

@rubyFeedback
Copy link

@rubyFeedback rubyFeedback commented Mar 23, 2020

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.

@thesamesam
Copy link

@thesamesam thesamesam commented Mar 23, 2020

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.

@memcached memcached locked as off topic and limited conversation to collaborators Mar 23, 2020
@dormando
Copy link
Member

@dormando dormando commented Mar 23, 2020

Locking this off-topic discussion.

@dormando
Copy link
Member

@dormando dormando commented Mar 23, 2020

1.6.2 released with fix: https://github.com/memcached/memcached/wiki/ReleaseNotes162
specifically: 02c6a2b

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.

@dormando dormando closed this Mar 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.