Nginx 安全漏洞集
2010-05-23 14:24:05 
阿炯
Nginx等保安全测评注意事项
1、身份鉴别
a)应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换；
b)应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施；
c)当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听；
d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。
由于Nginx中间件没有像Apache Tomcat一样的管理控制台，对于身份的鉴别还是依赖于操作系统层面。
2、访问控制
a)应对登录的用户分配账户和权限；
b)应重命名或删除默认账户，修改默认账户的默认口令；
c)应及时删除或停用多余的、过期的账户，避免共享账户的存在；
d)应授予管理用户所需的最小权限，实现管理用户的权限分离；
e)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；
f)访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级；
g)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问；
同样的原因，也是不适用。
3、安全审计
a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计
Nginx日志分为error.log错误日志和access.log访问日志，两种日志都开启就算是符合要求，可以查看配置文件nginx.conf，'access_log off;'表示关闭access_log，即不记录访问日志，没有此语句代表是默认开启的。
b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息
日志文件保存在nginx文件夹里的logs文件夹里，可以看到有access.log和error.log两类日志文件：日志文件会看到记录的一些信息，包括主机ip、日期和时间、状态等信息；可以在配置文件nginx.conf中的log_format参数设置日志内容参数。
c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等
定期备份最好查看一下日志的备份文件，并且询问管理员备份策略，至于避免受到未预期的删除、修改或覆盖等，就需要查看系统用户的权限了，选择日志文件右键单击属性，普通用户只有读取和执行的权限，没有删除、修改的权限。
d)应对审计进程进行保护，防止未经授权的中断
Nginx的审计进程都是跟主进程相关的，没有办法单独终止，所以默认符合。
4、入侵防范
a)应遵循最小安装的原则，仅安装需要的组件和应用程序
中间件不适用，可以到操作系统层面查看。
b)应关闭不需要的系统服务、默认共享和高危端口
中间件不适用，可以到操作系统层面查看。
c)应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制
同访问控制一样，不适用，可以到操作系统层面查看。
d)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求
同理不适用，可以到操作系统层面查看。
e)应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞
应该对中间件进行漏洞扫描或者渗透测试，并查看相关报告，是否存在高危漏洞，查看漏洞是否被修补。
f)应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警。
中间件不适用，可以到操作系统层面查看。
5、可信验证
a)可基于可信根对计算设备的系统引导程序、系统程序、重要配置参数和应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心。
中间件不适用，可以到操作系统层面查看。
6、数据完整性
a)应采用校验技术或密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；由于nginx中间件没有自己独立的登录界面，而是通过登录到操作系统进行中间件的管理，因此许多数据都是通过系统层面传输的，因此只要保证系统层面的数据完整性就可以了，但是审计数据如果需要备份保存，就需要查看备份策略是否有相关技术保证数据完整性。
b)应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；需要询问管理员在存储相关重要数据时，是否定期做完整性校验，一般采用对比前后哈希值的方法来验证。
7、数据保密性
a)应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等
由于nginx中间件没有自己独立的登录界面，而是通过登录到操作系统进行中间件的管理，因此许多数据都是通过系统层面传输的，因此只要保证系统层面的数据保密性就可以了，因此此项不适用。
Nginx 0day漏洞，上传图片可入侵百万台服务器
国内顶级安全团队80sec于5.20日下午6点发布了一个关于nginx的漏洞通告，由于该漏洞的存在，使用nginx+php组建的网站只要允许上传图片就可能被黑客入侵，直到5.21日凌晨，nginx尚未发布修复该漏洞的补丁；已经有一些网站被黑了，管理员速修复！
根据Netcraft的统计，直到2010年4月，全球一共有1300万台服务器运行着nginx程序；非常保守的估计，其中至少有600万台服务器运行着nginx并启用了php支持；继续保守的估计，其中有1/6，也就是100万台服务器允许用户上传图片。没错，重申一次，由于nginx有漏洞，这100万台服务器可能通过上传图片的方法被黑客轻易的植入木马。植入木马的过程也非常简单，就是把木马改成图片上传就是了，由于危害非常大，就不说细节了。
80sec团队由一群年轻、充满活力、充满体力、充满激情、富有创造力的未婚dota男组成，他们均在各大互联网公司从事信息安全工作，他们的口号 是know it then hack it，素包子非常认同这个观点：“我们只要非常熟悉一个事物，就有可能客观的发现它的不足之处，同时我们也能的发现该事物的优点”。
下面介绍一下他们的丰功伟绩，他们曾发现IIS、IE、FireFox、Maxthon、世界之窗、PHPWind、DeDeCMS、QQ mail、QuarkMail、EXTMail等软件的漏洞，可见硕果累累。既然介绍了80sec，就不得不介绍另外一个非常专注WEB安全的顶级安全团队80vul，该团队同样也是由80后的男童鞋组成(90后表示压力很大)，他们也发现了大量WEB APP的安全漏洞，例如IE、Gmail、wordpress、PHPWind、DISCUZ、MYBB等。
据说黑客已经在行动了；安全人员、系统管理人员、行动起来吧，赶紧修复该漏洞；最好不要有侥幸心理，否则下一个被黑客入侵的可能就是你的网站。根据 80sec安全公告的描述，临时修复方法如下，可3选其一。
1、设置php.ini的cgi.fix_pathinfo为0，重启php。最方便，但修改设置的影响需要自己评估。
2、给nginx的vhost配置添加如下内容，重启nginx。vhost较少的情况下也很方便。
if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}
3、禁止上传目录解释PHP程序。不需要动webserver，如果vhost和服务器较多，短期内难度急剧上升；建议在vhost和服务器较少的情况下采用。
Nginx严重的整数溢出漏洞
ngx_http_close_connection 函数整数溢出漏洞，由奇虎 360 Web 安全研究团队发现的 Nginx 一个严重的漏洞。该漏洞是由 Nginx 内部的 ngx_http_close_connection 函数由于整数溢出问题导致的，当 r->count 小于0或者大于255时，漏洞就会被远程攻击者通过恶意的 http 请求所利用。该漏洞影响 Nginx 所有的版本！
解决办法：验证 r->count input 的值。
Nginx 安全问题致使服务器易遭受 DoS 攻击
nginx 被爆出存在安全问题，有可能会致使 1400 多万台服务器易遭受 DoS 攻击，而导致安全问题的漏洞存在于 HTTP/2 和 MP4 模块中。已于2018年11月6日发布了新版本，用于修复影响 1.15.6, 1.14.1 之前版本的多个安全问题，被发现的安全问题有一种这样的情况 -- 允许潜在的攻击者触发拒绝服务(DoS)状态并访问敏感的信息。
“在 nginx HTTP/2 实现中发现了两个安全问题，这可能导致过多的内存消耗(CVE-2018-16843)和CPU使用率(CVE-2018-16844)”，详见 nginx 的安全建议。此外，“如果在配置文件中使用"listen"指令的"http2"选项，则问题会影响使用 ngx_http_v2_module 编译的 nginx(默认情况下不编译)。”为了利用上述两个问题，攻击者可以发送特制的 HTTP/2 请求，这将导致过多的CPU使用和内存使用，最终触发 DoS 状态。所有运行未打上补丁的 nginx 服务器都容易受到 DoS 攻击。
第三个安全问题(CVE-2018-16845)会影响 MP4 模块，使得攻击者在恶意制作的 MP4 文件的帮助下，在 worker 进程中导致出现无限循环、崩溃或内存泄露状态。最后一个安全问题仅影响运行使用 ngx_http_mp4_module 构建的 nginx 版本并在配置文件中启用 mp4 选项的服务器。总的来说，HTTP/2 漏洞影响 1.9.5 和 1.15.5 之间的所有 nginx 版本，MP4 模块安全问题影响运行 nginx 1.0.7, 1.1.3 及更高版本的服务器。为缓解这两个安全问题，服务器管理员必须将其 nginx 升级到 1.14.1 stable 或1.15.6 主线版本。
Nginx高危NS解析器Off-by-One堆写入漏洞
2021年5月27日，著名Web服务器和反向代理服务器Nginx暴出严重漏洞NS解析器Off-by-One堆写入漏洞(CVE-2021-23017)，该漏洞存在于Nginx的DNS解析模块ngx_resolver_copy()。攻击者可以利用该漏洞进行远程DDos攻击，甚至远程执行。ngx_resolver_copy()在处理DNS响应时出现一个off-by-one错误，利用该漏洞网络攻击者可以在堆分配的缓冲区中写一个点字符(.’, 0x2E)导致超出范围。 所有配置解析器语法的(resolver xxxx)Nginx实例可以通过DNS响应(响应来自Nginx的DNS请求)来触发该漏洞。特制数据包允许使用0x2E覆盖下一个堆块元数据的最低有效字节，利用该漏洞攻击者，可以实现Ddos拒绝服务，甚至可能实现远程代码执行。
由于Nginx中缺乏DNS欺骗缓解措施，并且在检查DNS事务ID之前调用了易受攻击的功能，因此远程攻击者可能能够通向中毒服务器注入受毒的DNS响应来利用此漏洞。
漏洞影响
严重等级：高
漏洞向量：远程/DNS
确认的受影响版本：0.6.18-1.20.0
确认的修补版本：1.21.0，1.20.1
供应商：F5，Inc.
状态：公开
CWE：193
CVSS得分：8.1
CVSS向量：CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
漏洞分析
当Nginx配置中设置resolver时，Nginx DNS解析器(core/ngx_resolver.c)用于通过DNS解析多个模块的主机名。Nginx中通过ngx_resolver_copy()调用来验证和解压缩DNS响应中包含的每个DNS域名，接收网络数据包作为输入和指向正在处理的名称的指针，并在成功后返回指向包含未压缩名称的新分配缓冲区的指针。调用整体上分两步完成的：
1)计算未压缩的域名大小的长度len并验证输入包的合法性，丢弃包含大于128个指针或包含超出输入缓冲区边界的域名。
2)分配输出缓冲区，并将未压缩的域名复制到其中。
第1部分中的大小计算与第2部分中的未压缩的域名之间的不匹配，导致一个len的一个off-by-one错误，导致允许以一个字节为单位写一个点字符超出name->data的边界。当压缩名称的最后一部分包含一个指向NUL字节的指针时，就会发生计算错误。尽管计算步骤仅考虑标签之间的点，但每次处理标签并且接着的字符为非NUL时，解压缩步骤都会写入一个点字符。当标签后跟指向NUL字节的指针时，解压缩过程将：
// 1) copy the label to the output buffer,
ngx_strlow(dst, src, n);
dst += n;
src += n;
// 2) read next character,
n = *src++;
// 3) as its a pointer, its not NUL,
if (n != 0){
// 4) so a dot character that was not accounted for is written out of bounds
*dst++ = '.';
// 5) Afterwards, the pointer is followed,
if (n & 0xc0){
n = ((n & 0x3f) << 8) + *src;
src = &buf[n];
n = *src++;
// 6) and a NULL byte is found, signaling the end of the function
if (n == 0){
name->len = dst - name->data;
return NGX_OK;
如果计算的大小恰好与堆块大小对齐，则超出范围的点字符将覆盖下一个堆块长度的元数据中的最低有效字节。这可能会直接导致下一个堆块的大小写入，但还会覆盖3个标志，从而导致 PREV_INUSE被清除并IS_MMAPPED被设置。
==7863== Invalid write of size 1
==7863== at 0x137C2E: ngx_resolver_copy (ngx_resolver.c:4018)
==7863== by 0x13D12B: ngx_resolver_process_a (ngx_resolver.c:2470)
==7863== by 0x13D12B: ngx_resolver_process_response (ngx_resolver.c:1844)
==7863== by 0x13D46A: ngx_resolver_udp_read (ngx_resolver.c:1574)
==7863== by 0x14AB19: ngx_epoll_process_events (ngx_epoll_module.c:901)
==7863== by 0x1414D4: ngx_process_events_and_timers (ngx_event.c:247)
==7863== by 0x148E57: ngx_worker_process_cycle (ngx_process_cycle.c:719)
==7863== by 0x1474DA: ngx_spawn_process (ngx_process.c:199)
==7863== by 0x1480A8: ngx_start_worker_processes (ngx_process_cycle.c:344)
==7863== by 0x14952D: ngx_master_process_cycle (ngx_process_cycle.c:130)
==7863== by 0x12237F: main (Nginx.c:383)
==7863== Address 0x4bbcfb8 is 0 bytes after a block of size 24 alloc'd
==7863== at 0x483E77F: malloc (vg_replace_malloc.c:307)
==7863== by 0x1448C4: ngx_alloc (ngx_alloc.c:22)
==7863== by 0x137AE4: ngx_resolver_alloc (ngx_resolver.c:4119)
==7863== by 0x137B26: ngx_resolver_copy (ngx_resolver.c:3994)
==7863== by 0x13D12B: ngx_resolver_process_a (ngx_resolver.c:2470)
==7863== by 0x13D12B: ngx_resolver_process_response (ngx_resolver.c:1844)
==7863== by 0x13D46A: ngx_resolver_udp_read (ngx_resolver.c:1574)
==7863== by 0x14AB19: ngx_epoll_process_events (ngx_epoll_module.c:901)
==7863== by 0x1414D4: ngx_process_events_and_timers (ngx_event.c:247)
==7863== by 0x148E57: ngx_worker_process_cycle (ngx_process_cycle.c:719)
==7863== by 0x1474DA: ngx_spawn_process (ngx_process.c:199)
==7863== by 0x1480A8: ngx_start_worker_processes (ngx_process_cycle.c:344)
==7863== by 0x14952D: ngx_master_process_cycle (ngx_process_cycle.c:130)
虽然目前还没有Poc出来，理论上该漏洞可以被用来进行远程代码执行。
攻击向量分析
DNS响应可以通过多种方式触发漏洞。首先Nginx必须发送了DNS请求，并且必须等待响应，然后可以在DNS响应的多个部分进行投毒：
DNS问题QNAME，
DNS回答名称，
DNS会回答RDATA以获得CNAME和SRV响应，
通过使用多个中毒的QNAME，NAME或RDATA值制作响应，可以在处理响应时多次击中易受攻击的函数，从而有效地执行多次脱机写入。
此外，当攻击者提供中毒的CNAME时，它将以递归方式解决，从而在执行过程中触发了额外的OOB写操作 ngx_resolve_name_locked() 调用ngx_strlow()(ngx_resolver.c：594)和其他OOB读取期间 ngx_resolver_dup()(ngx_resolver.c：790)和 ngx_crc32_short()(ngx_resolver.c：596)。
用于“example.net”请求的DNS响应示例负载，其中包含被污染的CNAME：
稍微不同的有效负载填充了足够的字节以覆盖next_chunk.mchunk_size带点的最低有效字节：
24字节的标签导致分配了24字节的缓冲区，该缓冲区填充有24字节+一个超出范围的点字符。
漏洞修复和解决：通过向域名解析时，在域名末尾写入的伪造的点字符分配一个额外的字节可以缓解此问题。
受漏洞影响的配置
http{
access_log logs/access.log;
server{
listen 8080;
location / {
resolver 127.0.0.1:1053;
set $dns example.net;
proxy_pass $dns;
}
}
Nginx 在MP4与HLS视频流媒体漏洞
nginx-1.22.1 稳定版和 nginx-1.23.2 主线版已于2022年10月下旬发布，其中包括了针对 ngx_http_mp4_module (CVE-2022-41741, CVE-2022-41742) 中内存损坏和内存泄漏的修复补丁。在 Nginx 模块 ngx_http_mp4_module 及 ngx_http_hls_module 中发现的漏洞：这两个模块用于以 MP4 以及 Apple HTTP Live Streaming (HLS) 格式进行视频流媒体处理。
漏洞: CVE-2022-41741
ngx_http_mp4_module
Nginx 在 ngx_http_mp4_module 中有一个漏洞，可能允许攻击者破坏 Nginx。使用特制的 mp4 文件可以损坏 worker 进程（负责流量处理）的内存，导致其终止或潜在的其他影响。该问题仅影响启用了 ngx_http_mp4_module 模块并在配置文件中使用 mp4 指令的 Nginx。此外，只有当攻击者能够触发使用 ngx_http_mp4_module 对特制 mp4 文件的进行处理时，攻击才有可能成功。
漏洞影响：一次成功的利用可能允许一个本地攻击者破坏 Nginx 的 worker 进程，导致其中止或其他潜在的影响。
缓解措施：ngx_http_mp4_module 模块为 MP4 文件提供伪流媒体的服务器侧支持，这些文件通常会使用 .mp4 .m4v 或.m4a 文件扩展名。
注意：默认情况下， Nginx 开源版本不包含 MP4 模块，必须启用该模块才受影响。MP4 模块默认包含在 Nginx Plus 中。缓解措施为：只允许受信用户发布音频和视频文件，或者在 Nginx 配置中禁用 MP4 模块，直到升级至修复版本。
漏洞: CVE-2022-41742
ngx_http_mp4_module
Nginx 在 ngx_http_mp4_module 中存在漏洞，这可能允许攻击者激发 worker 进程的崩溃，或者通过使用特制的 mp4 文件致使 worker 进程出现内存泄露。该问题仅影响启用了 ngx_http_mp4_module 模块（默认不启用）并在配置文件中使用 .mp4 指令的 Nginx。此外，只有当攻击者能够触发使用 ngx_http_mp4_module 对特制 mp4 文件的进行处理时，攻击才有可能成功。
漏洞影响：一次成功的利用可能允许一个攻击者破坏 Nginx 的 worker 进程，导致其中止或使其内存泄露。
缓解措施：ngx_http_mp4_module 模块为 MP4 文件提供伪流媒体的服务器侧支持，这些文件通常会使用 .mp4 .m4v 或 .m4a 文件扩展名。
注意：默认情况下， Nginx 开源版本不包含 MP4 模块，必须启用该模块才受影响。MP4 模块默认包含在 Nginx Plus 中。综上所述，缓解措施为：只允许受信用户发布音频和视频文件，或者在 Nginx 配置中禁用 MP4 模块，直到升级至修复版本。
漏洞: CVE-2022-41743
ngx_http_mp4_module
Nginx Plus 的模块 ngx_http_hls_module 中存在一个漏洞，该漏洞可能允许本地攻击者破坏 Nginx 的工作进程内存，从而导致其崩溃或在使用特制的音频或视频文件时产生其他潜在的影响。只有当配置文件中使用 hls 指令时，该问题才会影响 Nginx Plus。此外，只有当攻击者可以触发使用模块 ngx_http_hls_module 对特制音频或视频文件进行 处理时，攻击才有可能成功。
漏洞影响：一次成功的利用可能允许一个本地攻击者破坏 Nginx 的 worker 进程，导致其中止或其他潜在的影响。
缓解措施：ngx_http_hls_module 模块为 MP4 和 MOV 媒体文件提供 HTTP 流媒体服务器端支持。这类文件通常具有 .mp4 .m4v .m4a .mov 或 .qt 的文件名扩展名。该模块支持 H.264 视频编解码器，AAC 和 MP3 音频编解码器。
因此只允许受信用户发布音频和视频文件，或者在 Nginx 配置中禁用 HLS 模块，直到升级至修复版本，可缓解此风险。
Nginx NJS <0.7.4 存在释放后使用漏洞
Nginx NJS 是一种基于 JavaScript 开发的 Nginx 扩展，用于实现动态请求的处理和响应操作。
Nginx NJS 0.7.4 之前版本中的 njs_json.c 类中的 “njs_json_parse_iterator_call” 方法由于非法内存复制从而存在基于堆的释放后使用漏洞，攻击者可利用此漏洞造成拒绝服务或远程代码执行。
漏洞名称：Nginx NJS <0.7.4 存在释放后使用漏洞
漏洞类型：UAF
发现时间：2022-10-29
MPS 编号：MPS-2022-60231
CVE 编号：CVE-2022-43286
NJS <0.3.4 存在缓冲区溢出漏洞
漏洞源于 njs_module.c 中的 njs_module_read 函数中未对用户传入的 .js 文件进行验证，于2023年4月5日被发现，攻击者可通过传入恶意构造的 .js 文件造成堆的缓冲区溢出，进而远程执行恶意代码。
CVE 编号：CVE-2020-19692
影响范围：Nginx NJS@[0.1.0, 0.3.4)
修复方案：升级 Nginx NJS 到 0.3.4 或更高版本
1、身份鉴别
a)应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换；
b)应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施；
c)当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听；
d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。
由于Nginx中间件没有像Apache Tomcat一样的管理控制台，对于身份的鉴别还是依赖于操作系统层面。
2、访问控制
a)应对登录的用户分配账户和权限；
b)应重命名或删除默认账户，修改默认账户的默认口令；
c)应及时删除或停用多余的、过期的账户，避免共享账户的存在；
d)应授予管理用户所需的最小权限，实现管理用户的权限分离；
e)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；
f)访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级；
g)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问；
同样的原因，也是不适用。
3、安全审计
a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计
Nginx日志分为error.log错误日志和access.log访问日志，两种日志都开启就算是符合要求，可以查看配置文件nginx.conf，'access_log off;'表示关闭access_log，即不记录访问日志，没有此语句代表是默认开启的。
b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息
日志文件保存在nginx文件夹里的logs文件夹里，可以看到有access.log和error.log两类日志文件：日志文件会看到记录的一些信息，包括主机ip、日期和时间、状态等信息；可以在配置文件nginx.conf中的log_format参数设置日志内容参数。
c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等
定期备份最好查看一下日志的备份文件，并且询问管理员备份策略，至于避免受到未预期的删除、修改或覆盖等，就需要查看系统用户的权限了，选择日志文件右键单击属性，普通用户只有读取和执行的权限，没有删除、修改的权限。
d)应对审计进程进行保护，防止未经授权的中断
Nginx的审计进程都是跟主进程相关的，没有办法单独终止，所以默认符合。
4、入侵防范
a)应遵循最小安装的原则，仅安装需要的组件和应用程序
中间件不适用，可以到操作系统层面查看。
b)应关闭不需要的系统服务、默认共享和高危端口
中间件不适用，可以到操作系统层面查看。
c)应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制
同访问控制一样，不适用，可以到操作系统层面查看。
d)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求
同理不适用，可以到操作系统层面查看。
e)应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞
应该对中间件进行漏洞扫描或者渗透测试，并查看相关报告，是否存在高危漏洞，查看漏洞是否被修补。
f)应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警。
中间件不适用，可以到操作系统层面查看。
5、可信验证
a)可基于可信根对计算设备的系统引导程序、系统程序、重要配置参数和应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心。
中间件不适用，可以到操作系统层面查看。
6、数据完整性
a)应采用校验技术或密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；由于nginx中间件没有自己独立的登录界面，而是通过登录到操作系统进行中间件的管理，因此许多数据都是通过系统层面传输的，因此只要保证系统层面的数据完整性就可以了，但是审计数据如果需要备份保存，就需要查看备份策略是否有相关技术保证数据完整性。
b)应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；需要询问管理员在存储相关重要数据时，是否定期做完整性校验，一般采用对比前后哈希值的方法来验证。
7、数据保密性
a)应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等
由于nginx中间件没有自己独立的登录界面，而是通过登录到操作系统进行中间件的管理，因此许多数据都是通过系统层面传输的，因此只要保证系统层面的数据保密性就可以了，因此此项不适用。
Nginx 0day漏洞，上传图片可入侵百万台服务器
国内顶级安全团队80sec于5.20日下午6点发布了一个关于nginx的漏洞通告，由于该漏洞的存在，使用nginx+php组建的网站只要允许上传图片就可能被黑客入侵，直到5.21日凌晨，nginx尚未发布修复该漏洞的补丁；已经有一些网站被黑了，管理员速修复！
根据Netcraft的统计，直到2010年4月，全球一共有1300万台服务器运行着nginx程序；非常保守的估计，其中至少有600万台服务器运行着nginx并启用了php支持；继续保守的估计，其中有1/6，也就是100万台服务器允许用户上传图片。没错，重申一次，由于nginx有漏洞，这100万台服务器可能通过上传图片的方法被黑客轻易的植入木马。植入木马的过程也非常简单，就是把木马改成图片上传就是了，由于危害非常大，就不说细节了。
80sec团队由一群年轻、充满活力、充满体力、充满激情、富有创造力的未婚dota男组成，他们均在各大互联网公司从事信息安全工作，他们的口号 是know it then hack it，素包子非常认同这个观点：“我们只要非常熟悉一个事物，就有可能客观的发现它的不足之处，同时我们也能的发现该事物的优点”。
下面介绍一下他们的丰功伟绩，他们曾发现IIS、IE、FireFox、Maxthon、世界之窗、PHPWind、DeDeCMS、QQ mail、QuarkMail、EXTMail等软件的漏洞，可见硕果累累。既然介绍了80sec，就不得不介绍另外一个非常专注WEB安全的顶级安全团队80vul，该团队同样也是由80后的男童鞋组成(90后表示压力很大)，他们也发现了大量WEB APP的安全漏洞，例如IE、Gmail、wordpress、PHPWind、DISCUZ、MYBB等。
据说黑客已经在行动了；安全人员、系统管理人员、行动起来吧，赶紧修复该漏洞；最好不要有侥幸心理，否则下一个被黑客入侵的可能就是你的网站。根据 80sec安全公告的描述，临时修复方法如下，可3选其一。
1、设置php.ini的cgi.fix_pathinfo为0，重启php。最方便，但修改设置的影响需要自己评估。
2、给nginx的vhost配置添加如下内容，重启nginx。vhost较少的情况下也很方便。
if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}
3、禁止上传目录解释PHP程序。不需要动webserver，如果vhost和服务器较多，短期内难度急剧上升；建议在vhost和服务器较少的情况下采用。
Nginx严重的整数溢出漏洞
ngx_http_close_connection 函数整数溢出漏洞，由奇虎 360 Web 安全研究团队发现的 Nginx 一个严重的漏洞。该漏洞是由 Nginx 内部的 ngx_http_close_connection 函数由于整数溢出问题导致的，当 r->count 小于0或者大于255时，漏洞就会被远程攻击者通过恶意的 http 请求所利用。该漏洞影响 Nginx 所有的版本！
解决办法：验证 r->count input 的值。
Nginx 安全问题致使服务器易遭受 DoS 攻击
nginx 被爆出存在安全问题，有可能会致使 1400 多万台服务器易遭受 DoS 攻击，而导致安全问题的漏洞存在于 HTTP/2 和 MP4 模块中。已于2018年11月6日发布了新版本，用于修复影响 1.15.6, 1.14.1 之前版本的多个安全问题，被发现的安全问题有一种这样的情况 -- 允许潜在的攻击者触发拒绝服务(DoS)状态并访问敏感的信息。
“在 nginx HTTP/2 实现中发现了两个安全问题，这可能导致过多的内存消耗(CVE-2018-16843)和CPU使用率(CVE-2018-16844)”，详见 nginx 的安全建议。此外，“如果在配置文件中使用"listen"指令的"http2"选项，则问题会影响使用 ngx_http_v2_module 编译的 nginx(默认情况下不编译)。”为了利用上述两个问题，攻击者可以发送特制的 HTTP/2 请求，这将导致过多的CPU使用和内存使用，最终触发 DoS 状态。所有运行未打上补丁的 nginx 服务器都容易受到 DoS 攻击。
第三个安全问题(CVE-2018-16845)会影响 MP4 模块，使得攻击者在恶意制作的 MP4 文件的帮助下，在 worker 进程中导致出现无限循环、崩溃或内存泄露状态。最后一个安全问题仅影响运行使用 ngx_http_mp4_module 构建的 nginx 版本并在配置文件中启用 mp4 选项的服务器。总的来说，HTTP/2 漏洞影响 1.9.5 和 1.15.5 之间的所有 nginx 版本，MP4 模块安全问题影响运行 nginx 1.0.7, 1.1.3 及更高版本的服务器。为缓解这两个安全问题，服务器管理员必须将其 nginx 升级到 1.14.1 stable 或1.15.6 主线版本。
Nginx高危NS解析器Off-by-One堆写入漏洞
2021年5月27日，著名Web服务器和反向代理服务器Nginx暴出严重漏洞NS解析器Off-by-One堆写入漏洞(CVE-2021-23017)，该漏洞存在于Nginx的DNS解析模块ngx_resolver_copy()。攻击者可以利用该漏洞进行远程DDos攻击，甚至远程执行。ngx_resolver_copy()在处理DNS响应时出现一个off-by-one错误，利用该漏洞网络攻击者可以在堆分配的缓冲区中写一个点字符(.’, 0x2E)导致超出范围。 所有配置解析器语法的(resolver xxxx)Nginx实例可以通过DNS响应(响应来自Nginx的DNS请求)来触发该漏洞。特制数据包允许使用0x2E覆盖下一个堆块元数据的最低有效字节，利用该漏洞攻击者，可以实现Ddos拒绝服务，甚至可能实现远程代码执行。
由于Nginx中缺乏DNS欺骗缓解措施，并且在检查DNS事务ID之前调用了易受攻击的功能，因此远程攻击者可能能够通向中毒服务器注入受毒的DNS响应来利用此漏洞。
漏洞影响
严重等级：高
漏洞向量：远程/DNS
确认的受影响版本：0.6.18-1.20.0
确认的修补版本：1.21.0，1.20.1
供应商：F5，Inc.
状态：公开
CWE：193
CVSS得分：8.1
CVSS向量：CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
漏洞分析
当Nginx配置中设置resolver时，Nginx DNS解析器(core/ngx_resolver.c)用于通过DNS解析多个模块的主机名。Nginx中通过ngx_resolver_copy()调用来验证和解压缩DNS响应中包含的每个DNS域名，接收网络数据包作为输入和指向正在处理的名称的指针，并在成功后返回指向包含未压缩名称的新分配缓冲区的指针。调用整体上分两步完成的：
1)计算未压缩的域名大小的长度len并验证输入包的合法性，丢弃包含大于128个指针或包含超出输入缓冲区边界的域名。
2)分配输出缓冲区，并将未压缩的域名复制到其中。
第1部分中的大小计算与第2部分中的未压缩的域名之间的不匹配，导致一个len的一个off-by-one错误，导致允许以一个字节为单位写一个点字符超出name->data的边界。当压缩名称的最后一部分包含一个指向NUL字节的指针时，就会发生计算错误。尽管计算步骤仅考虑标签之间的点，但每次处理标签并且接着的字符为非NUL时，解压缩步骤都会写入一个点字符。当标签后跟指向NUL字节的指针时，解压缩过程将：
// 1) copy the label to the output buffer,
ngx_strlow(dst, src, n);
dst += n;
src += n;
// 2) read next character,
n = *src++;
// 3) as its a pointer, its not NUL,
if (n != 0){
// 4) so a dot character that was not accounted for is written out of bounds
*dst++ = '.';
// 5) Afterwards, the pointer is followed,
if (n & 0xc0){
n = ((n & 0x3f) << 8) + *src;
src = &buf[n];
n = *src++;
// 6) and a NULL byte is found, signaling the end of the function
if (n == 0){
name->len = dst - name->data;
return NGX_OK;
如果计算的大小恰好与堆块大小对齐，则超出范围的点字符将覆盖下一个堆块长度的元数据中的最低有效字节。这可能会直接导致下一个堆块的大小写入，但还会覆盖3个标志，从而导致 PREV_INUSE被清除并IS_MMAPPED被设置。
==7863== Invalid write of size 1
==7863== at 0x137C2E: ngx_resolver_copy (ngx_resolver.c:4018)
==7863== by 0x13D12B: ngx_resolver_process_a (ngx_resolver.c:2470)
==7863== by 0x13D12B: ngx_resolver_process_response (ngx_resolver.c:1844)
==7863== by 0x13D46A: ngx_resolver_udp_read (ngx_resolver.c:1574)
==7863== by 0x14AB19: ngx_epoll_process_events (ngx_epoll_module.c:901)
==7863== by 0x1414D4: ngx_process_events_and_timers (ngx_event.c:247)
==7863== by 0x148E57: ngx_worker_process_cycle (ngx_process_cycle.c:719)
==7863== by 0x1474DA: ngx_spawn_process (ngx_process.c:199)
==7863== by 0x1480A8: ngx_start_worker_processes (ngx_process_cycle.c:344)
==7863== by 0x14952D: ngx_master_process_cycle (ngx_process_cycle.c:130)
==7863== by 0x12237F: main (Nginx.c:383)
==7863== Address 0x4bbcfb8 is 0 bytes after a block of size 24 alloc'd
==7863== at 0x483E77F: malloc (vg_replace_malloc.c:307)
==7863== by 0x1448C4: ngx_alloc (ngx_alloc.c:22)
==7863== by 0x137AE4: ngx_resolver_alloc (ngx_resolver.c:4119)
==7863== by 0x137B26: ngx_resolver_copy (ngx_resolver.c:3994)
==7863== by 0x13D12B: ngx_resolver_process_a (ngx_resolver.c:2470)
==7863== by 0x13D12B: ngx_resolver_process_response (ngx_resolver.c:1844)
==7863== by 0x13D46A: ngx_resolver_udp_read (ngx_resolver.c:1574)
==7863== by 0x14AB19: ngx_epoll_process_events (ngx_epoll_module.c:901)
==7863== by 0x1414D4: ngx_process_events_and_timers (ngx_event.c:247)
==7863== by 0x148E57: ngx_worker_process_cycle (ngx_process_cycle.c:719)
==7863== by 0x1474DA: ngx_spawn_process (ngx_process.c:199)
==7863== by 0x1480A8: ngx_start_worker_processes (ngx_process_cycle.c:344)
==7863== by 0x14952D: ngx_master_process_cycle (ngx_process_cycle.c:130)
虽然目前还没有Poc出来，理论上该漏洞可以被用来进行远程代码执行。
攻击向量分析
DNS响应可以通过多种方式触发漏洞。首先Nginx必须发送了DNS请求，并且必须等待响应，然后可以在DNS响应的多个部分进行投毒：
DNS问题QNAME，
DNS回答名称，
DNS会回答RDATA以获得CNAME和SRV响应，
通过使用多个中毒的QNAME，NAME或RDATA值制作响应，可以在处理响应时多次击中易受攻击的函数，从而有效地执行多次脱机写入。
此外，当攻击者提供中毒的CNAME时，它将以递归方式解决，从而在执行过程中触发了额外的OOB写操作 ngx_resolve_name_locked() 调用ngx_strlow()(ngx_resolver.c：594)和其他OOB读取期间 ngx_resolver_dup()(ngx_resolver.c：790)和 ngx_crc32_short()(ngx_resolver.c：596)。
用于“example.net”请求的DNS响应示例负载，其中包含被污染的CNAME：
稍微不同的有效负载填充了足够的字节以覆盖next_chunk.mchunk_size带点的最低有效字节：
24字节的标签导致分配了24字节的缓冲区，该缓冲区填充有24字节+一个超出范围的点字符。
漏洞修复和解决：通过向域名解析时，在域名末尾写入的伪造的点字符分配一个额外的字节可以缓解此问题。
受漏洞影响的配置
http{
access_log logs/access.log;
server{
listen 8080;
location / {
resolver 127.0.0.1:1053;
set $dns example.net;
proxy_pass $dns;
}
}
Nginx 在MP4与HLS视频流媒体漏洞
nginx-1.22.1 稳定版和 nginx-1.23.2 主线版已于2022年10月下旬发布，其中包括了针对 ngx_http_mp4_module (CVE-2022-41741, CVE-2022-41742) 中内存损坏和内存泄漏的修复补丁。在 Nginx 模块 ngx_http_mp4_module 及 ngx_http_hls_module 中发现的漏洞：这两个模块用于以 MP4 以及 Apple HTTP Live Streaming (HLS) 格式进行视频流媒体处理。
漏洞: CVE-2022-41741
ngx_http_mp4_module
Nginx 在 ngx_http_mp4_module 中有一个漏洞，可能允许攻击者破坏 Nginx。使用特制的 mp4 文件可以损坏 worker 进程（负责流量处理）的内存，导致其终止或潜在的其他影响。该问题仅影响启用了 ngx_http_mp4_module 模块并在配置文件中使用 mp4 指令的 Nginx。此外，只有当攻击者能够触发使用 ngx_http_mp4_module 对特制 mp4 文件的进行处理时，攻击才有可能成功。
漏洞影响：一次成功的利用可能允许一个本地攻击者破坏 Nginx 的 worker 进程，导致其中止或其他潜在的影响。
缓解措施：ngx_http_mp4_module 模块为 MP4 文件提供伪流媒体的服务器侧支持，这些文件通常会使用 .mp4 .m4v 或.m4a 文件扩展名。
注意：默认情况下， Nginx 开源版本不包含 MP4 模块，必须启用该模块才受影响。MP4 模块默认包含在 Nginx Plus 中。缓解措施为：只允许受信用户发布音频和视频文件，或者在 Nginx 配置中禁用 MP4 模块，直到升级至修复版本。
漏洞: CVE-2022-41742
ngx_http_mp4_module
Nginx 在 ngx_http_mp4_module 中存在漏洞，这可能允许攻击者激发 worker 进程的崩溃，或者通过使用特制的 mp4 文件致使 worker 进程出现内存泄露。该问题仅影响启用了 ngx_http_mp4_module 模块（默认不启用）并在配置文件中使用 .mp4 指令的 Nginx。此外，只有当攻击者能够触发使用 ngx_http_mp4_module 对特制 mp4 文件的进行处理时，攻击才有可能成功。
漏洞影响：一次成功的利用可能允许一个攻击者破坏 Nginx 的 worker 进程，导致其中止或使其内存泄露。
缓解措施：ngx_http_mp4_module 模块为 MP4 文件提供伪流媒体的服务器侧支持，这些文件通常会使用 .mp4 .m4v 或 .m4a 文件扩展名。
注意：默认情况下， Nginx 开源版本不包含 MP4 模块，必须启用该模块才受影响。MP4 模块默认包含在 Nginx Plus 中。综上所述，缓解措施为：只允许受信用户发布音频和视频文件，或者在 Nginx 配置中禁用 MP4 模块，直到升级至修复版本。
漏洞: CVE-2022-41743
ngx_http_mp4_module
Nginx Plus 的模块 ngx_http_hls_module 中存在一个漏洞，该漏洞可能允许本地攻击者破坏 Nginx 的工作进程内存，从而导致其崩溃或在使用特制的音频或视频文件时产生其他潜在的影响。只有当配置文件中使用 hls 指令时，该问题才会影响 Nginx Plus。此外，只有当攻击者可以触发使用模块 ngx_http_hls_module 对特制音频或视频文件进行 处理时，攻击才有可能成功。
漏洞影响：一次成功的利用可能允许一个本地攻击者破坏 Nginx 的 worker 进程，导致其中止或其他潜在的影响。
缓解措施：ngx_http_hls_module 模块为 MP4 和 MOV 媒体文件提供 HTTP 流媒体服务器端支持。这类文件通常具有 .mp4 .m4v .m4a .mov 或 .qt 的文件名扩展名。该模块支持 H.264 视频编解码器，AAC 和 MP3 音频编解码器。
因此只允许受信用户发布音频和视频文件，或者在 Nginx 配置中禁用 HLS 模块，直到升级至修复版本，可缓解此风险。
Nginx NJS <0.7.4 存在释放后使用漏洞
Nginx NJS 是一种基于 JavaScript 开发的 Nginx 扩展，用于实现动态请求的处理和响应操作。
Nginx NJS 0.7.4 之前版本中的 njs_json.c 类中的 “njs_json_parse_iterator_call” 方法由于非法内存复制从而存在基于堆的释放后使用漏洞，攻击者可利用此漏洞造成拒绝服务或远程代码执行。
漏洞名称：Nginx NJS <0.7.4 存在释放后使用漏洞
漏洞类型：UAF
发现时间：2022-10-29
MPS 编号：MPS-2022-60231
CVE 编号：CVE-2022-43286
NJS <0.3.4 存在缓冲区溢出漏洞
漏洞源于 njs_module.c 中的 njs_module_read 函数中未对用户传入的 .js 文件进行验证，于2023年4月5日被发现，攻击者可通过传入恶意构造的 .js 文件造成堆的缓冲区溢出，进而远程执行恶意代码。
CVE 编号：CVE-2020-19692
影响范围：Nginx NJS@[0.1.0, 0.3.4)
修复方案：升级 Nginx NJS 到 0.3.4 或更高版本
该文章最后由 阿炯 于 2023-04-12 10:34:59 更新，目前是第 2 版。