- 主题:log4j 0-day 漏洞
js很好扫描啊，分秒被第三方工具扫出来
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 但保不齐第三方库用了啊。
: 企业级的 JAVA 都这样子，不知道那些用 JS 写后端的怎么看。里面不知道有多少 eval() 等着黑客呵呵。
--
FROM 27.91.71.*
就是java特有的，
JNDI，log4j的解析变量，这二者同时起作用，少一个都不会出问题。
asp.net、js都可能会加载远程服务器上的code，不过默认都有限制，打开限制的人对此负责。
不知道java这个加载remote byte code是怎么默认就能绕过限制的，没细究。
【 在 nikezhang 的大作中提到: 】
: 和java无关，是log4j自作聪明了，logback就没有这问题
--
FROM 114.245.195.*
反思，我最近也干过一个类似的事，而且没干好
【 在 adoal (阿豆) 的大作中提到: 】
: 但是没有比Java圈更热爱这种over design的了
--
FROM 180.158.0.*
业级的 JAVA 都这样子，不知道那些用 PYTHON 写后端的怎么看。里面不知道有多少 eval() 等着黑客呵呵
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 但保不齐第三方库用了啊。
: 企业级的 JAVA 都这样子，不知道那些用 JS 写后端的怎么看。里面不知道有多少 eval() 等着黑客呵呵。
--
FROM 203.211.107.*
这玩应是销售用来忽悠人用的，你还真相信啊
并且相信了这个，用openssl之类的库就觉着很安心，实际更方便FBI CIA内嵌私货，实
际上没有几个人会看源代码，看了也不一定能发现问题。核心部门可能会看，甚至自己
完全重新实现一部分功能
【 在 No1 () No1 () 的大作中提到: 】
: intel cpu还出漏洞呢，都一个德行
: 说是开源更安全，我咋觉得源码、文档、开发者等啥都不透露才最安全呢
--
FROM 221.200.2.*
闭源更不安全已经没有争议了
就拿加密协议来说，闭源的几乎100%有bug，也没人敢用
【 在 laoshifu (老师傅) 的大作中提到: 】
: 标 题: Re: log4j 0-day 漏洞
: 发信站: 水木社区 (Wed Dec 15 09:43:28 2021), 站内
:
:
: 这玩应是销售用来忽悠人用的，你还真相信啊
:
: 并且相信了这个，用openssl之类的库就觉着很安心，实际更方便FBI CIA内嵌私货，实
: 际上没有几个人会看源代码，看了也不一定能发现问题。核心部门可能会看，甚至自己
: 完全重新实现一部分功能
:
:
: 【 在 No1 () No1 () 的大作中提到: 】
: : intel cpu还出漏洞呢，都一个德行
: : 说是开源更安全，我咋觉得源码、文档、开发者等啥都不透露才最安全呢
:
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 221.200.2.*]
--
FROM 27.91.71.*
写日志的时候需要执行远程代码。这种应用场景是什么？我觉得没什么这种需求啊。为啥会有这种设计。
【 在 nikezhang (难得糊涂) 的大作中提到: 】
: 主要是jndi，rmi这种远程执行代码，稍微不注意就会中招，其他语言如果提供这种远程调用也一样
--
FROM 114.249.28.*
写日志的时候希望把jvm、服务状态啥的打印出来，提供了口子
结果玩大了
【 在 chunhui (北瓜) 的大作中提到: 】
: 写日志的时候需要执行远程代码。这种应用场景是什么？我觉得没什么这种需求啊。为啥会有这种设计。
--
FROM 117.136.0.*
好吧
【 在 licy 的大作中提到: 】
: 写日志的时候希望把jvm、服务状态啥的打印出来，提供了口子
: 结果玩大了
:
: ...................
--
FROM 114.249.28.*
这种提供配置支持就行，提供给最终输入端做啥
【 在 licy (上网不便, msg收不到) 的大作中提到: 】
: 写日志的时候希望把jvm、服务状态啥的打印出来，提供了口子
: 结果玩大了
--
FROM 183.6.114.*