Re: Review+CVE request: multiple issues in redis EVAL command (lua sandbox)

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> https://github.com/antirez/redis/issues/2854
> https://github.com/antirez/redis/issues/2853
> https://github.com/antirez/redis/issues/2855

As far as we can tell, 2854 and 2853 do not need to be categorized as
vulnerability reports, but 2855 is a report of at least one
vulnerability. See the initial CVE ID assignment below.


> https://github.com/antirez/redis/issues/2854

> the whole "strict lua" in scriptingEnableGlobalsProtection() can be
> bypassed with a simple setmetatable(_G, nil)

We are not currently planning to assign any CVE IDs for cases in which
a security-relevant impact has a requirement of malicious lines of
code in a script. For example, http://antirez.com/news/96 says 'The
Redis security model is: "it's totally insecure to let untrusted
clients access the system, please protect it from the outside world
yourself".' More specifically,
https://github.com/antirez/redis/issues/1725#issuecomment-42382547
says 'the Redis documentation recognizes this flaw and says "Using Lua
debugging functionality or other approaches like altering the meta
table used to implement global protections in order to circumvent
globals protection is not hard. However it is difficult to do it
accidentally. If the user messes with the Lua global state, the
consistency of AOF and replication is not guaranteed: don't do it."
Redis is just trying to stop people from accidentally screwing
themselves, not intentionally doing so.' Our feeling is that the
sandboxing is not (yet) intended to define a security boundary with
any practical value, and thus ability to defeat the sandboxing will
not have a CVE ID at present.


> https://github.com/antirez/redis/issues/2853

> it is possible to de-synchronize redis dict and LUA global environment
> via maliciously crafted scripts.

> In fact, a simple PoC can be constructed with two identical EVAL
> commands:

> $ echo 'setfenv(0,{})' > /tmp/redis-crash.lua
> $ redis-cli --eval /tmp/redis-crash.lua
> (nil)
> $ redis-cli --eval /tmp/redis-crash.lua
> Error: Server closed the connection

Similarly, we are not currently planning to assign any CVE IDs for
cases in which a security-relevant impact has a requirement of lines
of code that, although not inherently malicious, are crafted to
trigger a bug.


> https://github.com/antirez/redis/issues/2855

We feel that this is an entirely different situation because the
attack can realistically originate from someone who cannot control any
aspect of the code, but can control data that happens to be used by
the code. For example, suppose that a legitimate user has written a
script that satisfies the above "not intentionally ... screwing
themselves" principle, and the script has been tested (although not
comprehensively) and seems to be reliable for an intended, normal type
of functionality. The attacker's role is to insert the number
2147483648 into a data set on which the script operates, and trigger a
crash. We feel that this can have at least one CVE ID.

Use CVE-2015-8080 for the "getnum ... integer wraparound ... thus
returning a negative value" vulnerability.

2855 also says "optsize() has no lower bound/negative check." If this
is an independently exploitable problem, then it can have its own CVE
ID. We think it's conceivable that that bounds check isn't necessarily
required after getnum has been fixed, so we haven't yet assigned a
unique CVE ID. In addition, 2855 also says "optsize() ... an implicit
int -> size_t promotion, yielding a very large (unsigned) size value."
Again, we think it's conceivable that that becomes largely irrelevant
after getnum has been fixed, so we haven't yet assigned a unique CVE
ID. Similarly, "further int/size_t confusion in the whole module"
might be exploitable only with a problematic getnum, and there isn't
any additional CVE ID for any aspect of that set of issues.

Finally,
https://www.reddit.com/r/redis/comments/3rby8c/a_few_things_about_redis_security/
mentions "especially since the vulnerabilities you reported could
crash the server just because Lua scripts that happened to be just
bugged and not malicious." We don't see any reasonable way to use that
statement as a basis for CVE assignments, i.e., the server is intended
to be robust in the face of all script coding errors but not robust in
the face of script coding manipulations. Even if the vendor wanted a
CVE ID for each case where a script coding error caused a crash, we
would be very reluctant to do that. Instead, as mentioned above, our
preference is to have a CVE ID only in the case of an attack with
crafted data, where that data realistically has a different origin
than the code.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWPN2UAAoJEL54rhJi8gl5vG0P/RpQaMn4vLpl8tdlXc6VxsIO
Qh2gZSrquTceb39tjIZZLrXQM9h6QR3fS/mqcJ/1qpECsilC1Yz+LGJEDK8VsJ+B
fRr+FqCDWsAHiTLC0JNC/s2XEhB0GJocJNGVxS5PqqAqD1zO6RMmBdhuWzatJEXZ
vbhe/O/OPIhu9vWnKRvPKqXJJt4OuhXywxZI5NiXwE97ZYvpVrmf5/iIvn1oEee1
UqWOjWKRASNvgq7nxw/0wBqLx/Kq9hanSp29VyfXWMNZI08+aZ/HTPUHboRt1q3+
nyVcOc2aHNgWi+nRImEqyIABAA9A/tGFX4GfICSKs0Ld0JujeufSuYVvOnTXg3dx
AlvvwtToZsg+jMxWnbpKp4PmoXDTIFs4O6di5LtFPz+/a4QOVhKeGf3xbZzQ960w
AfmS+pgLnTA8q7NRbiSQcbmx34nM6fHcRzWQx2DePxSvH2WtFMHsoUmKQpxb0bDV
IJU974kJyccGXYS5oLK2qGsGb0v1LfvVS70MS6Vl9FO9w/+TgxH2M9jb3FmEJ/zA
rTrLlLslM51YGtPHy0jnU05qv5V73fddQybWJxMze1azbNPP1x0u6JHF42Up/tE2
VAWugdcf0GDE8anUCr4LpU4k1f8DJxgQCJWDr9qOFZTqZSkSWmqkkhoMmcQocW2e
+BEkogZ/ljYuTBpCqW5E
=KWRY
-----END PGP SIGNATURE-----