Elasticsearch是否受最新的fastjson反序列化漏洞的影响？
原创Elasticsearch是否受最新的fastjson反序列化漏洞的影响？
原创
今天（2022年5月25日）接国家网络与信息安全信息通报中心预警，开源Java开发组件fastjson存在反序列化漏洞。攻击者可利用上述漏洞实施任意文件写入、服务端请求伪造等攻击行为，造成服务器权限被窃取、敏感信息泄漏等严重影响。
使用Elasticsearch service的同学可能会比较关心，我们运行于腾讯云上的Elasticsearch service是否会受到这个漏洞的影响？
Elasticsearch的Java包依赖
我们可以通过官方文档的Elasticsearch依赖查看是否有使用到fastjson:
elasticsearch = 8.2.2
lucene = 9.1.0
bundled_jdk_vendor = openjdk
bundled_jdk = 18.0.1.1+2@65ae32619e2f40f3a9af3af1851d6e19
checkstyle = 9.3
# optional dependencies
spatial4j = 0.7
jts = 1.15.0
jackson = 2.10.4
snakeyaml = 1.26
icu4j = 68.2
supercsv = 2.4.0
log4j = 2.17.1
slf4j = 1.6.2
ecsLogging = 1.2.0
jna = 5.10.0
netty = 4.1.74.Final
commons_lang3 = 3.9
# when updating this version, you need to ensure compatibility with:
# - plugins/ingest-attachment (transitive dependency, check the upstream POM)
# - distribution/tools/plugin-cli
# - x-pack/plugin/security
bouncycastle=1.64
# used by security and idp (need to be in sync due to cross-dependency in testing)
opensaml = 4.0.1
# test dependencies
randomizedrunner = 2.7.7
junit = 4.12
junit5 = 5.7.1
httpclient = 4.5.10
httpcore = 4.4.12
httpasyncclient = 4.1.4
commonslogging = 1.1.3
commonscodec = 1.14
hamcrest = 2.1
mocksocket = 1.2
# benchmark dependencies
jmh = 1.26
# test dependencies
# when updating this version, also update :qa:evil-tests
jimfs = 1.2
jimfs_guava = 30.1-jre
# test framework
networknt_json_schema_validator = 1.0.48可以看到Elasticsearch并没有使用到fastjson，对应的Elasticsearch使用的是jackson
Elasticsearch漏洞排查
如果不放心，在官网的安全事件中，也可以查看官方公布的整个Elastic Stack的各个组件，在各个版本上存在的漏洞：
fastjson vs jackson
对于Elasticsearch的JSON库，为什么选择jackson，这里转发知乎上的一篇文章《fastjson这么快老外为啥还是热衷 jackson?》，以下为其中一个答主的回答：
在2014-2015年的时候，我曾经是fastjson和温少的铁粉，非常钦佩温少和他的这个项目。温少几乎凭一己之力撑起了一个被广泛使用JSON库，而其他库几乎都是靠一整个团队，就凭这一点，温少作为“初心不改的阿里初代开源人”，当之无愧。
后来随着时间，温少这种“一个人扛一个项目”的模式开始慢慢显露出弊端：代码质量不过关、bug多、对社区的反馈不及时等。我自己的项目也逐步切到了Jackson——主要是想用同一份代码同时处理JSON和YAML。
另外说一个很小的点：这些年给fastjson提过一些PR，翻之前的PR时候，我震惊地发现几个月前的PR全都变成了这个样子：
很明显，温少force push过。force push的原因不得而知，但是我猜想可能是为了隐藏某个包含安全漏洞的commit。如果是这样的话反而欲盖弥彰——只要拿原始仓库和被fork的仓库一对比，攻击者不就立刻能找到“你想隐藏的那个commit”了么？
更别提force push给协作带来的问题了，至少我们的master都是开启禁止force push的。还记得么？
If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble, and the scorn of your teammates. 假如在那些已经被推送至共用仓库的提交上执行变基命令，并因此丢弃了一些别人的开发所基于的提交，那你就有大麻烦了，你的同事也会因此鄙视你。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
