如何通过数据包套接字攻击Linux内核
一、前言
最近我花了一些時間使用syzkaller工具對Linux內核中與網絡有關的接口進行了模糊測試（fuzz）。除了最近發現的DCCP套接字漏洞之外，我還發現了另一個漏洞，該漏洞位于數據包套接字（packet sockets）中。在這篇文章中，我會向大家介紹這個漏洞的發現過程，以及我們如何利用這個漏洞來提升權限。
該漏洞本身（CVE-2017-7308）是一個符號類型漏洞，會導致堆越界（heap-out-of-bounds）寫入問題。在啟用TPACKET_V3版本的環形緩沖區（ring buffer）條件下，我們可以通過為AF_PACKET套接字的PACKET_RX_RING選項提供特定的參數來觸發這個漏洞。漏洞觸發成功后，在“net/packet/af_packet.c”源碼中，“packet_set_ring()”函數中的完整性檢查過程就會被繞過，最終導致越界訪問。“packet_set_ring()”函數中的完整性檢查過程如下所示：
| 1 2 3 4 | 4207?????????????????if?(po->tp_version?>=?TPACKET_V3?&& 4208?????????????????????(int)(req->tp_block_size?- 4209???????????????????????????BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv))?<=?0) 4210?????????????????????????goto?out; |
2011年8月19日，這個bug與TPACKET_V3的實現一起提交到Github上編號為f6fb8f10的commit（“af-packet：TPACKET_V3靈活緩沖區的實現”）。2014年8月15日，在編號為dc808110的commit中，人們嘗試通過添加額外的檢查流程來修復這個bug，但根據本文的分析，我們發現這個修復過程并不完美。這個bug最終于2017年3月29日在編號為2b6867c2的commit中被修復。
如果Linux內核啟用了AF_PACKET套接字選項（CONFIG_PACKET=y），那么它就會受到這個漏洞影響，而大多數Linux分發版內核都啟用了該選項。漏洞利用需要具備CAP_NET_RAW權限，才能創建這類套接字。然而，如果啟用了用戶命名空間（user namespace，通過CONFIG_USER_NS=y實現），我們就可能在用戶命名空間中使用非特權用戶來利用這個漏洞。
由于數據包套接字是Linux內核中廣泛應用的一個功能，因此這個漏洞會影響包括Ubuntu、Android在內的許多流行的Linux發行版。需要注意的是，Android中除了某些特權組件之外，明確禁止任何未受信代碼訪問AF_PACKET套接字。新版的Ubuntu內核已經發布，此外Android也計劃在7月份推出更新。
二、Syzkaller簡介
我使用syzkaller以及KASAN工具發現了這個bug。Syzkaller是一款針對Linux系統調用的覆蓋型模糊測試器，KASAN是一款動態內存錯誤檢測器。我會向大家介紹syzkaller的工作原理，以及如何使用該工具對某些內核接口進行模糊測試，方便大家掌握這個工具。
讓我們先來看看syzkaller模糊測試器如何工作。在為每個系統調用（syscall）手動編寫描述模板的基礎上，syzkaller可以（按照syscall的調用順序）生成隨機的程序。這個模糊測試器會運行這些程序，收集每個程序的代碼覆蓋情況。通過代碼覆蓋信息，syzkaller會保存一個程序語料庫，觸發內核中的不同代碼路徑。每當新的程序觸發了一條新的代碼路徑（也就是說給出了新的覆蓋信息），syzkaller就會將其添加到語料庫中。除了生成全新的程序之外，syzkaller也可以更改語料庫中的已有程序。
Syzkaller最好搭配動態錯誤檢測器一起使用，如KASAN（從4.0版開始就可以檢測諸如越界訪問（out-of-bounds）以及釋放后重用（use-after-free）之類的內存錯誤）、KMSAN（可以檢查未初始化內存使用錯誤，原型版本剛剛發布）或者KTSAN（可以檢測數據沖突（data race）錯誤，原型版本已發布）之類的動態錯誤檢測器都可以。Syzkaller可以對內核進行壓力測試，執行各種有趣的代碼路徑，然后錯誤檢測器就能檢測并報告對應的錯誤。
使用syzkaller查找錯誤的通常流程如下：
1、確保已正確安裝syzkaller。可以參考使用說明以及wiki中的詳細安裝步驟。
2、為待測試的特定內核接口編寫模板描述。
3、在syzkaller選項中，指定該接口具體使用的系統調用。
4、運行syzkaller，直到它發現錯誤為止。通常情況下，如果該接口之前尚未使用syzkaller進行測試，那么這個過程會比較快。
Syzkaller自己有一套聲明語言，用來描述系統調用模板。我們可以參考sys/sys.txt中給出的樣例，也可以參考sys/README.md給出的語法信息。以下內容截取自我所使用的syzkaller描述信息，用來發現AF_PACKET套接字上的錯誤：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | resource?sock_packet[sock] define?ETH_P_ALL_BE?htons(ETH_P_ALL) socket$packet(domain?const[AF_PACKET],?type?flags[packet_socket_type],?proto?const[ETH_P_ALL_BE])?sock_packet packet_socket_type?=?SOCK_RAW,?SOCK_DGRAM setsockopt$packet_rx_ring(fd?sock_packet,?level?const[SOL_PACKET],?optname?const[PACKET_RX_RING],?optval?ptr[in,?tpacket_req_u],?optlen?len[optval]) setsockopt$packet_tx_ring(fd?sock_packet,?level?const[SOL_PACKET],?optname?const[PACKET_TX_RING],?optval?ptr[in,?tpacket_req_u],?optlen?len[optval]) tpacket_req?{ ?tp_block_size??int32 ?tp_block_nr??int32 ?tp_frame_size??int32 ?tp_frame_nr??int32 } tpacket_req3?{ ?tp_block_size??int32 ?tp_block_nr??int32 ?tp_frame_size??int32 ?tp_frame_nr??int32 ?tp_retire_blk_tov?int32 ?tp_sizeof_priv?int32 ?tp_feature_req_word?int32 } tpacket_req_u?[ ?req??tpacket_req ?req3??tpacket_req3 ]?[varlen] |
大多數語法我們一看就能明白。首先，我們聲明了一個新的sock_packet類型。這種類型繼承自現有的sock類型。這樣一來，對于使用sock類型作為參數的系統調用而言，syzkaller也會在sock_packet類型的套接字上使用這種系統調用。
在這之后，我們聲明了一個新的系統調用：socket$packet。“$”符號之前的部分作用是告訴syzkaller應該使用哪種系統調用，而“$”符號之后的部分用來區分同一種系統調用的不同類型。這種方式在處理類似ioctl的系統調用時非常有用。“socket$packet”系統調用會返回一個sock_packet套接字。
然后我們聲明了setsockopt$packet_rx_ring以及setsockopt$packet_tx_ring。這些系統調用會在sock_packet套接字上設置PACKET_RX_RING以及PACKET_TX_RING套接字選項。我會在下文討論這兩個選項的具體細節。這兩者都使用了tpacket_req_u聯合體（union）作為套接字選項的值。tpacket_req_u聯合體包含兩個結構體成員，分別為tpacket_req以及tpacket_req3。
一旦描述信息添加完畢，我們就可以使用syzkaller對與數據包相關的系統調用進行模糊測試。我在syzkaller管理配置選項中的設置信息如下所示：
| 1 2 3 | "enable_syscalls":?[ ??"socket$packet",?"socketpair$packet",?"accept$packet",?"accept4$packet",?"bind$packet",?"connect$packet",?"sendto$packet",?"recvfrom$packet",?"getsockname$packet",?"getpeername$packet",?"listen",?"setsockopt",?"getsockopt",?"syz_emit_ethernet" ?], |
使用這些描述信息運行syzkaller一段時間之后，我開始觀察到內核崩潰現象。某個syzkaller應用所觸發的bug如下所示：
| 1 2 3 4 | mmap(&(0x7f0000000000/0xc8f000)=nil,?(0xc8f000),?0x3,?0x32,?0xffffffffffffffff,?0x0) r0?=?socket$packet(0x11,?0x3,?0x300) setsockopt$packet_int(r0,?0x107,?0xa,?&(0x7f000061f000)=0x2,?0x4) setsockopt$packet_rx_ring(r0,?0x107,?0x5,?&(0x7f0000c8b000)=@req3={0x10000,?0x3,?0x10000,?0x3,?0x4,?0xfffffffffffffffe,?0x5},?0x1c) |
KASAN的某個報告如下所示。需要注意的是，由于訪問點距離數據塊邊界非常遠，因此分配和釋放棧沒有對應溢出（overflown）對象。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 | ================================================================== BUG:?KASAN:?slab-out-of-bounds?in?prb_close_block?net/packet/af_packet.c:808 Write?of?size?4?at?addr?ffff880054b70010?by?task?syz-executor0/30839 CPU:?0?PID:?30839?Comm:?syz-executor0?Not?tainted?4.11.0-rc2+?#94 Hardware?name:?QEMU?Standard?PC?(i440FX?+?PIIX,?1996),?BIOS?Bochs?01/01/2011 Call?Trace: ?__dump_stack?lib/dump_stack.c:16?[inline] ?dump_stack+0x292/0x398?lib/dump_stack.c:52 ?print_address_description+0x73/0x280?mm/kasan/report.c:246 ?kasan_report_error?mm/kasan/report.c:345?[inline] ?kasan_report.part.3+0x21f/0x310?mm/kasan/report.c:368 ?kasan_report?mm/kasan/report.c:393?[inline] ?__asan_report_store4_noabort+0x2c/0x30?mm/kasan/report.c:393 ?prb_close_block?net/packet/af_packet.c:808?[inline] ?prb_retire_current_block+0x6ed/0x820?net/packet/af_packet.c:970 ?__packet_lookup_frame_in_block?net/packet/af_packet.c:1093?[inline] ?packet_current_rx_frame?net/packet/af_packet.c:1122?[inline] ?tpacket_rcv+0x9c1/0x3750?net/packet/af_packet.c:2236 ?packet_rcv_fanout+0x527/0x810?net/packet/af_packet.c:1493 ?deliver_skb?net/core/dev.c:1834?[inline] ?__netif_receive_skb_core+0x1cff/0x3400?net/core/dev.c:4117 ?__netif_receive_skb+0x2a/0x170?net/core/dev.c:4244 ?netif_receive_skb_internal+0x1d6/0x430?net/core/dev.c:4272 ?netif_receive_skb+0xae/0x3b0?net/core/dev.c:4296 ?tun_rx_batched.isra.39+0x5e5/0x8c0?drivers/net/tun.c:1155 ?tun_get_user+0x100d/0x2e20?drivers/net/tun.c:1327 ?tun_chr_write_iter+0xd8/0x190?drivers/net/tun.c:1353 ?call_write_iter?include/linux/fs.h:1733?[inline] ?new_sync_write?fs/read_write.c:497?[inline] ?__vfs_write+0x483/0x760?fs/read_write.c:510 ?vfs_write+0x187/0x530?fs/read_write.c:558 ?SYSC_write?fs/read_write.c:605?[inline] ?SyS_write+0xfb/0x230?fs/read_write.c:597 ?entry_SYSCALL_64_fastpath+0x1f/0xc2 RIP:?0033:0x40b031 RSP:?002b:00007faacbc3cb50?EFLAGS:?00000293?ORIG_RAX:?0000000000000001 RAX:?ffffffffffffffda?RBX:?000000000000002a?RCX:?000000000040b031 RDX:?000000000000002a?RSI:?0000000020002fd6?RDI:?0000000000000015 RBP:?00000000006e2960?R08:?0000000000000000?R09:?0000000000000000 R10:?0000000000000000?R11:?0000000000000293?R12:?0000000000708000 R13:?000000000000002a?R14:?0000000020002fd6?R15:?0000000000000000 Allocated?by?task?30534: ?save_stack_trace+0x16/0x20?arch/x86/kernel/stacktrace.c:59 ?save_stack+0x43/0xd0?mm/kasan/kasan.c:513 ?set_track?mm/kasan/kasan.c:525?[inline] ?kasan_kmalloc+0xad/0xe0?mm/kasan/kasan.c:617 ?kasan_slab_alloc+0x12/0x20?mm/kasan/kasan.c:555 ?slab_post_alloc_hook?mm/slab.h:456?[inline] ?slab_alloc_node?mm/slub.c:2720?[inline] ?slab_alloc?mm/slub.c:2728?[inline] ?kmem_cache_alloc+0x1af/0x250?mm/slub.c:2733 ?getname_flags+0xcb/0x580?fs/namei.c:137 ?getname+0x19/0x20?fs/namei.c:208 ?do_sys_open+0x2ff/0x720?fs/open.c:1045 ?SYSC_open?fs/open.c:1069?[inline] ?SyS_open+0x2d/0x40?fs/open.c:1064 ?entry_SYSCALL_64_fastpath+0x1f/0xc2 Freed?by?task?30534: ?save_stack_trace+0x16/0x20?arch/x86/kernel/stacktrace.c:59 ?save_stack+0x43/0xd0?mm/kasan/kasan.c:513 ?set_track?mm/kasan/kasan.c:525?[inline] ?kasan_slab_free+0x72/0xc0?mm/kasan/kasan.c:590 ?slab_free_hook?mm/slub.c:1358?[inline] ?slab_free_freelist_hook?mm/slub.c:1381?[inline] ?slab_free?mm/slub.c:2963?[inline] ?kmem_cache_free+0xb5/0x2d0?mm/slub.c:2985 ?putname+0xee/0x130?fs/namei.c:257 ?do_sys_open+0x336/0x720?fs/open.c:1060 ?SYSC_open?fs/open.c:1069?[inline] ?SyS_open+0x2d/0x40?fs/open.c:1064 ?entry_SYSCALL_64_fastpath+0x1f/0xc2 Object?at?ffff880054b70040?belongs?to?cache?names_cache?of?size?4096 The?buggy?address?belongs?to?the?page: page:ffffea000152dc00?count:1?mapcount:0?mapping:??????????(null)?index:0x0?compound_mapcount:?0 flags:?0x500000000008100(slab|head) raw:?0500000000008100?0000000000000000?0000000000000000?0000000100070007 raw:?ffffea0001549a20?ffffea0001b3cc20?ffff88003eb44f40?0000000000000000 page?dumped?because:?kasan:?bad?access?detected Memory?state?around?the?buggy?address: ?ffff880054b6ff00:?00?00?00?00?00?00?00?00?00?00?00?00?00?00?00?00 ?ffff880054b6ff80:?00?00?00?00?00?00?00?00?00?00?00?00?00?00?00?00 >ffff880054b70000:?fc?fc?fc?fc?fc?fc?fc?fc?fb?fb?fb?fb?fb?fb?fb?fb ?????????????????????????^ ?ffff880054b70080:?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb ?ffff880054b70100:?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb?fb ================================================================== |
你可以參考syzkaller的代碼倉庫以了解更多細節，也可以參考KASAN的內核文檔部分了解更多細節。如果你在使用syzkaller或者KASAN的過程中遇到任何問題，可以發郵件到syzkaller@googlegroups.com以及kasan-dev@googlegroups.com進行咨詢。
三、AF_PACKET套接字簡介
為了更好了解這個bug、bug所引發的漏洞以及如何利用這個漏洞，我們需要了解AF_PACKET套接字的相關內容，理解它們在內核中的具體實現方式。
3.1 概要
用戶可以使用AF_PACKET在設備驅動層發送或者接受數據包。這樣一來，用戶就可以在物理層之上實現自己的協議，也可以嗅探包含以太網和更高層協議頭部的數據包。為了創建一個AF_PACKET套接字，進程必須在用戶命名空間中具備CAP_NET_RAW權限，以便管理進程的網絡命名空間（network namespace）。你可以參考數據包套接字文檔了解更多細節。需要注意的是，如果內核啟用了非特權用戶命名空間，那么非特權用戶就能創建數據包套接字。
進程可以使用send和recv這兩個系統調用在數據包套接字上發送和接受數據包。然而，數據包套接字提供了一個環形緩沖區（ring buffer）方式使數據包的發送和接受更為高效，這個環形緩沖區可以在內核和用戶空間之間共享使用。我們可以使用PACKET_TX_RING以及PACKET_RX_RING套接字選項創建環形緩沖區。之后，用戶可以使用內存映射方式（mmap）映射這個緩沖區，這樣包數據就能直接讀取和寫入到這個緩沖區中。
內核在處理環形緩沖區時有幾種不同的處理方式。用戶可以使用PACKET_VERSION這個套接字選項選擇具體使用的方式。我們可以參考內核文檔（搜索“TPACKET versions”關鍵字），了解不同版本的環形緩沖區之間的區別。
人們熟知的AF_PACKET套接字的一個應用就是tcpdump工具。使用tcpdump嗅探某個接口上的所有數據包時，處理流程如下所示：
| 1 2 3 4 5 6 7 8 9 10 11 12 | #?strace?tcpdump?-i?eth0 ... socket(PF_PACKET,?SOCK_RAW,?768)????????=?3 ... bind(3,?{sa_family=AF_PACKET,?proto=0x03,?if2,?pkttype=PACKET_HOST,?addr(0)={0,?},?20)?=?0 ... setsockopt(3,?SOL_PACKET,?PACKET_VERSION,?[1],?4)?=?0 ... setsockopt(3,?SOL_PACKET,?PACKET_RX_RING,?{block_size=131072,?block_nr=31,?frame_size=65616,?frame_nr=31},?16)?=?0 ... mmap(NULL,?4063232,?PROT_READ|PROT_WRITE,?MAP_SHARED,?3,?0)?=?0x7f73a6817000 ... |
以上系統調用的順序對應如下操作：
1、創建一個套接字：socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL))；
2、套接字綁定到eth0接口；
3、通過PACKET_VERSION套接字選項，將環形緩沖區版本設置為TPACKET_V2；
4、使用PACKET_RX_RING套接字選項，創建一個環形緩沖區；
5、將環形緩沖區映射到用戶空間。
在這之后，內核開始將來自于eth0接口的所有數據包存入環形緩沖區中，然后tcpdump會從用戶空間中對應的映射區域讀取這些數據包。
3.2 環形緩沖區（ring buffers）
讓我們了解一下如何在數據包套接字上使用環形緩沖區。出于一致性考慮，我們在下文引用的代碼片段全部來自于4.8版Linux內核。這個內核也是最新的Ubuntu 16.04.2所使用的內核。
現有的文檔主要關注的是TPACKET_V1以及TPACKET_V2版的環形緩沖區。由于本文提到的bug只影響TPACKET_V3版，因此我在下文假設我們處理的都是TPACKET_V3版。另外，我主要關注的是PACKET_RX_RING選項，會忽略另一個PACKET_TX_RING選項。
一個環形緩沖區就是一塊存放數據包的內存區域。每個數據包會存放在一個單獨的幀（frame）中，多個幀會被分組形成內存塊。在TPACKET_V3環形緩沖區中，幀的大小是不固定的，只要幀能夠存放到內存塊中，它的大小就可以取任意值。
為了使用PACKET_RX_RING套接字選項創建TPACKET_V3環形緩沖區，用戶必須為環形緩沖區提供準確的參數值。這些參數會通過一個指向tpacket_req3結構體的指針傳遞給setsockopt調用，該結構體的定義如下所示：
| 1 2 3 4 5 6 7 8 9 | 274?struct?tpacket_req3?{ 275?????????unsigned?int????tp_block_size;??/*?Minimal?size?of?contiguous?block?*/ 276?????????unsigned?int????tp_block_nr;????/*?Number?of?blocks?*/ 277?????????unsigned?int????tp_frame_size;??/*?Size?of?frame?*/ 278?????????unsigned?int????tp_frame_nr;????/*?Total?number?of?frames?*/ 279?????????unsigned?int????tp_retire_blk_tov;?/*?timeout?in?msecs?*/ 280?????????unsigned?int????tp_sizeof_priv;?/*?offset?to?private?data?area?*/ 281?????????unsigned?int????tp_feature_req_word; 282?}; |
tpacket_req3結構體中每個字段的含義如下所示：
1、tp_block_size：每個內存塊的大小；
2、tp_block_nr：內存塊的個數；
3、tp_frame_size：每個幀的大小，TPACKET_V3會忽視這個字段；
4、tp_frame_nr：幀的個數，TPACKET_V3會忽視這個字段；
5、tp_retire_blk_tov：超時時間（毫秒），超時后即使內存塊沒有被數據完全填滿也會被內核停用（參考下文）；
6、tp_sizeof_priv：每個內存塊中私有區域的大小。用戶可以使用這個區域存放與每個內存塊有關的任何信息；
7、tp_feature_req_word：一組標志（目前實際上只有一個標志），可以用來啟動某些附加功能。
每個內存塊都有一個頭部與之相關，該頭部存放在為這個內存塊所分配的內存空間的開頭部位。內存塊的頭部結構為tpacket_block_desc，這個結構中有一個block_status字段，該字段用來標識內存塊目前是否正在被內核使用，還是可以提供給用戶使用。在通常的工作流程中，內核會將數據包存儲在某個內存塊中，直到該內存塊被填滿，之后內核會將block_status字段設置為TP_STATUS_USER。之后用戶就可以從內存塊中讀取所需的數據，讀取完畢后，會將block_status設置為TP_STATUS_KERNEL，以便釋放內存塊，歸還給內核使用。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | 186?struct?tpacket_hdr_v1?{ 187?????????__u32???block_status; 188?????????__u32???num_pkts; 189?????????__u32???offset_to_first_pkt; ... 233?}; 234? 235?union?tpacket_bd_header_u?{ 236?????????struct?tpacket_hdr_v1?bh1; 237?}; 238? 239?struct?tpacket_block_desc?{ 240?????????__u32?version; 241?????????__u32?offset_to_priv; 242?????????union?tpacket_bd_header_u?hdr; 243?}; |
同樣，每個幀也有一個與之關聯的頭部，頭部結構為tpacket3_hdr，其中tp_next_offset字段指向同一個內存塊中的下一個幀。
| 1 2 3 4 | 162?struct?tpacket3_hdr?{ 163?????????__u32??tp_next_offset; ... 176?}; |
當某個內存塊完全被數據填滿時（即新的數據包不會填充到剩余的空間中），內存塊就會被關閉然后釋放到用戶空間中（也就是說被內核停用）。由于通常情況下，用戶希望盡可能快地看到數據包，因此內核有可能會提前釋放某個內存塊，即使該內存塊還沒有被數據完全填滿。內核會維護一個計時器，使用tp_retire_blk_tov參數控制超時時間，當超時發生時就會停用當前的內存塊。
還有一種方式，那就是指定每個塊的私有區域，內核不會觸碰這個私有區域，用戶可以使用該區域存儲與內存塊有關的任何信息。這個區域的大小通過tp_sizeof_priv參數進行傳遞。
如果你想更加詳細了解用戶空間程序如何使用TPACKET_V3環形緩沖區，你可以閱讀官方文檔中提供的具體示例（搜索“TPACKET_V3 example”關鍵詞）。
四、AF_PACKET套接字的具體實現
我們來快速了解一下AF_PACKET在內核中的具體實現。
4.1 結構體定義
每當創建一個數據包套接字時，內核中就會分配與之對應的一個packet_sock結構體對象，如下所示：
| 1 2 3 4 5 6 7 8 9 10 11 12 | 103?struct?packet_sock?{ ... 105?????????struct?sock?????????????sk; ... 108?????????struct?packet_ring_buffer???????rx_ring; 109?????????struct?packet_ring_buffer???????tx_ring; ... 123?????????enum?tpacket_versions???tp_version; ... 130?????????int?????????????????????(*xmit)(struct?sk_buff?*skb); ... 132?}; |
這個結構體中，tp_version字段保存了環形緩沖區的版本，在本文案例中，我們通過setsockopt調用，傳入PACKET_VERSION參數，將環形緩沖區的版本設置為TPACKET_V3。rx_ring以及tx_ring字段代表接收（receive）和傳輸（transmit）環形緩沖區，這類緩沖區使用設置了PACKET_RX_RING和PACKET_TX_RING選項的setsockopt調用來創建。這兩個字段的類型為packet_ring_buffer，此類型的定義如下：
| 1 2 3 4 5 | 56?struct?packet_ring_buffer?{ 57?????????struct?pgv??????????????*pg_vec; ... 70?????????struct?tpacket_kbdq_core????????prb_bdqc; 71?}; |
其中pg_vec字段為指向pgv結構體數組的一個指針，數組中的每個元素都保存了對某個內存塊的引用。每個內存塊實際上都是單獨分配的，沒有位于一個連續的內存區域中。
| 1 2 3 | 52?struct?pgv?{ 53?????????char?*buffer; 54?}; |
prb_bdqc字段的類型為tpacket_kbdq_core結構體，這個結構體的字段描述了環形緩沖區的當前狀態，如下所示：
| 1 2 3 4 5 6 7 8 | 14?struct?tpacket_kbdq_core?{ ... 21?????????unsigned?short??blk_sizeof_priv; ... 36?????????char????????????*nxt_offset; ... 49?????????struct?timer_list?retire_blk_timer; 50?}; |
其中blk_sizeof_priv字段包含每個內存塊所屬的私有區域的大小。nxt_offset字段指向當前活躍的內存塊的內部區域，表明下一個數據包的存放位置。retire_blk_timer字段的類型為timer_list結構體，用來描述超時發生后停用當前內存塊的那個計時器，如下所示：
| 1 2 3 4 5 6 7 8 | 12?struct?timer_list?{ ... 17?????????struct?hlist_node???????entry; 18?????????unsigned?long???????????expires; 19?????????void????????????????????(*function)(unsigned?long); 20?????????unsigned?long???????????data; ... 31?}; |
4.2 設置環形緩沖區
內核使用packet_setsockopt()函數處理數據包套接字的選項設置操作。當使用PACKET_VERSION套接字選項時，內核就會將po->tp_version參數的值設置為對應的值。
在這之后，內核會使用PACKET_RX_RING套接字選項，創建一個用于數據包接收的環形緩沖區。內核使用packet_set_ring()函數完成這一過程。這個函數做了很多工作，因此我只是摘抄其中比較重要的那部分代碼。首先，packet_set_ring()函數會對給定的環形緩沖區參數執行一系列完整性檢查操作，如下所示：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | 4202?????????????????err?=?-EINVAL; 4203?????????????????if?(unlikely((int)req->tp_block_size?<=?0)) 4204?????????????????????????goto?out; 4205?????????????????if?(unlikely(!PAGE_ALIGNED(req->tp_block_size))) 4206?????????????????????????goto?out; 4207?????????????????if?(po->tp_version?>=?TPACKET_V3?&& 4208?????????????????????(int)(req->tp_block_size?- 4209???????????????????????????BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv))?<=?0) 4210?????????????????????????goto?out; 4211?????????????????if?(unlikely(req->tp_frame_size?<?po->tp_hdrlen?+ 4212?????????????????????????????????????????po->tp_reserve)) 4213?????????????????????????goto?out; 4214?????????????????if?(unlikely(req->tp_frame_size?&?(TPACKET_ALIGNMENT?-?1))) 4215?????????????????????????goto?out; 4216? 4217?????????????????rb->frames_per_block?=?req->tp_block_size?/?req->tp_frame_size; 4218?????????????????if?(unlikely(rb->frames_per_block?==?0)) 4219?????????????????????????goto?out; 4220?????????????????if?(unlikely((rb->frames_per_block?*?req->tp_block_nr)?!= 4221?????????????????????????????????????????req->tp_frame_nr)) 4222?????????????????????????goto?out; |
之后，函數會分配環形緩沖區的內存塊空間：
| 1 2 3 4 5 | 4224?????????????????err?=?-ENOMEM; 4225?????????????????order?=?get_order(req->tp_block_size); 4226?????????????????pg_vec?=?alloc_pg_vec(req,?order); 4227?????????????????if?(unlikely(!pg_vec)) 4228?????????????????????????goto?out; |
我們應該注意到，alloc_pg_vec()函數使用了內核頁分配器來分配內存塊（我們會在漏洞利用中使用這個方法）：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | 4104?static?char?*alloc_one_pg_vec_page(unsigned?long?order) 4105?{ ... 4110?????????buffer?=?(char?*)?__get_free_pages(gfp_flags,?order); 4111?????????if?(buffer) 4112?????????????????return?buffer; ... 4127?} 4128? 4129?static?struct?pgv?*alloc_pg_vec(struct?tpacket_req?*req,?int?order) 4130?{ ... 4139?????????for?(i?=?0;?i?<?block_nr;?i++)?{ 4140?????????????????pg_vec[i].buffer?=?alloc_one_pg_vec_page(order); ... 4143?????????} ... 4152?} |
最后，packet_set_ring()函數會調用init_prb_bdqc()函數，后者會通過一些額外的操作，創建一個接收數據包的TPACKET_V3環形緩沖區：
| 1 2 3 4 5 6 7 8 9 | 4229?????????????????switch?(po->tp_version)?{ 4230?????????????????case?TPACKET_V3: ... 4234?????????????????????????if?(!tx_ring) 4235?????????????????????????????????init_prb_bdqc(po,?rb,?pg_vec,?req_u); 4236?????????????????????????break; 4237?????????????????default: 4238?????????????????????????break; 4239?????????????????} |
init_prb_bdqc()函數會將環形緩沖區參數拷貝到環形緩沖區結構體中的prb_bdqc字段，在這些參數的基礎上計算其他一些參數值，設置停用內存塊的計時器，然后調用prb_open_block()函數初始化第一個內存塊：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | 604?static?void?init_prb_bdqc(struct?packet_sock?*po, 605?????????????????????????struct?packet_ring_buffer?*rb, 606?????????????????????????struct?pgv?*pg_vec, 607?????????????????????????union?tpacket_req_u?*req_u) 608?{ 609?????????struct?tpacket_kbdq_core?*p1?=?GET_PBDQC_FROM_RB(rb); 610?????????struct?tpacket_block_desc?*pbd; ... 616?????????pbd?=?(struct?tpacket_block_desc?*)pg_vec[0].buffer; 617?????????p1->pkblk_start?=?pg_vec[0].buffer; 618?????????p1->kblk_size?=?req_u->req3.tp_block_size; ... 630?????????p1->blk_sizeof_priv?=?req_u->req3.tp_sizeof_priv; 631? 632?????????p1->max_frame_len?=?p1->kblk_size?-?BLK_PLUS_PRIV(p1->blk_sizeof_priv); 633?????????prb_init_ft_ops(p1,?req_u); 634?????????prb_setup_retire_blk_timer(po); 635?????????prb_open_block(p1,?pbd); 636?} |
prb_open_block()函數做了一些事情，比如它會設置tpacket_kbdq_core結構體中的nxt_offset字段，將其指向緊挨著每個內存塊私有區域的那個地址。
| 1 2 3 4 5 6 7 8 | 841?static?void?prb_open_block(struct?tpacket_kbdq_core?*pkc1, 842?????????struct?tpacket_block_desc?*pbd1) 843?{ ... 862?????????pkc1->pkblk_start?=?(char?*)pbd1; 863?????????pkc1->nxt_offset?=?pkc1->pkblk_start?+?BLK_PLUS_PRIV(pkc1->blk_sizeof_priv); ... 876?} |
4.3 數據包接收
每當內核收到一個新的數據包時，內核應該會把它保存到環形緩沖區中。內核所使用的關鍵函數為__packet_lookup_frame_in_block()，這個函數的主要工作為：
1、檢查當前活躍的內存塊是否有充足的空間存放數據包；
2、如果空間足夠，保存數據包到當前的內存塊，然后返回；
3、如果空間不夠，就調度下一個內存塊，將數據包保存到下一個內存塊。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | 1041?static?void?*__packet_lookup_frame_in_block(struct?packet_sock?*po, 1042?????????????????????????????????????????????struct?sk_buff?*skb, 1043?????????????????????????????????????????????????int?status, 1044?????????????????????????????????????????????unsigned?int?len 1045?????????????????????????????????????????????) 1046?{ 1047?????????struct?tpacket_kbdq_core?*pkc; 1048?????????struct?tpacket_block_desc?*pbd; 1049?????????char?*curr,?*end; 1050? 1051?????????pkc?=?GET_PBDQC_FROM_RB(&po->rx_ring); 1052?????????pbd?=?GET_CURR_PBLOCK_DESC_FROM_CORE(pkc); ... 1075?????????curr?=?pkc->nxt_offset; 1076?????????pkc->skb?=?skb; 1077?????????end?=?(char?*)pbd?+?pkc->kblk_size; 1078? 1079?????????/*?first?try?the?current?block?*/ 1080?????????if?(curr+TOTAL_PKT_LEN_INCL_ALIGN(len)?<?end)?{ 1081?????????????????prb_fill_curr_block(curr,?pkc,?pbd,?len); 1082?????????????????return?(void?*)curr; 1083?????????} 1084? 1085?????????/*?Ok,?close?the?current?block?*/ 1086?????????prb_retire_current_block(pkc,?po,?0); 1087? 1088?????????/*?Now,?try?to?dispatch?the?next?block?*/ 1089?????????curr?=?(char?*)prb_dispatch_next_block(pkc,?po); 1090?????????if?(curr)?{ 1091?????????????????pbd?=?GET_CURR_PBLOCK_DESC_FROM_CORE(pkc); 1092?????????????????prb_fill_curr_block(curr,?pkc,?pbd,?len); 1093?????????????????return?(void?*)curr; 1094?????????} ... 1101?} |
五、漏洞分析
5.1 Bug分析
讓我們仔細分析一下packet_set_ring()函數中的檢查過程，如下所示：
| 1 2 3 4 | 4207?????????????????if?(po->tp_version?>=?TPACKET_V3?&& 4208?????????????????????(int)(req->tp_block_size?- 4209???????????????????????????BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv))?<=?0) 4210?????????????????????????goto?out; |
這個檢查過程的目的是確保內存塊頭部加上每個內存塊私有數據的大小不超過內存塊自身的大小。這個檢查非常有必要，否則我們在內存塊中就不會有足夠的空間，更不用說能夠預留空間存放數據包了。
然而，事實證明這個檢查過程可以被繞過。如果我們設置了req_u->req3.tp_sizeof_priv的高位字節，那么將這個賦值表達式轉換為整數（int）則會導致一個非常大的正整數值（而不是負值）。如下所示：
| 1 2 3 4 5 | A?=?req->tp_block_size?=?4096?=?0x1000 B?=?req_u->req3.tp_sizeof_priv?=?(1?<<?31)?+?4096?=?0x80001000 BLK_PLUS_PRIV(B)?=?(1?<<?31)?+?4096?+?48?=?0x80001030 A?-?BLK_PLUS_PRIV(B)?=?0x1000?-?0x80001030?=?0x7fffffd0 (int)0x7fffffd0?=?0x7fffffd0?>?0 |
之后，在init_prb_bdqc()函數中，當req_u->req3.tp_sizeof_priv被復制到p1->blk_sizeof_priv時（參考前文提到的代碼片段），它會被分割成兩個低位字節，而后者的類型是unsigned short。因此我們可以利用這個bug，將tpacket_kbdq_core結構體中的blk_sizeof_priv設置為任意值，以繞過所有的完整性檢查過程。
5.2 漏洞后果
如果我們遍歷net/packet/af_packet.c的源碼，搜索blk_sizeof_priv的用法，我們會發現源碼中有兩處使用了這個函數。
第一個調用位于init_prb_bdqc()函數中，此時blk_sizeof_priv剛被賦值，用來設置max_frame_len變量的值。p1->max_frame_len的值代表可以保存到內存塊中的某個幀大小的最大值。由于我們可以控制p1->blk_sizeof_priv，我們可以使BLK_PLUS_PRIV(p1->blk_sizeof_priv)的值大于p1->kblk_size的值。這樣會導致p1->max_frame_len取的一個非常大的值，比內存塊的大小更大。這樣當某個幀被拷貝到內存塊中時，我們就可以繞過對它的大小檢測過程，最終導致內核堆越界寫入問題。
問題還不僅限于此，blk_sizeof_priv的另一個調用位于prb_open_block()函數中，這個函數用來初始化一個內存塊（參考上文的代碼片段）。在這個函數中，當內核收到新的數據包時，數據包的寫入地址存放在pkc1->nxt_offset中。內核不想覆蓋內存塊頭部以及內存塊對應的私有數據，因此它會將這個地址指向緊挨著頭部和私有數據之后的那個地址。由于我們可以控制blk_sizeof_priv，因此我們也可以控制nxt_offset的最低的兩個字節。這樣我們就能夠控制越界寫入的偏移量。
總而言之，這個bug會導致內核堆越界寫入，我們能控制的大小和偏移量最多可達64k字節。
六、漏洞利用
現在讓我們研究下如何利用這個漏洞。我的目標系統是x86-64架構的Ubuntu 16.04.2，內核版本為4.8.0-41-generic，內核啟用了KASLR、SMEP以及SMAP選項。Ubuntu內核為非特權用戶啟用了用戶命名空間（CONFIG_USER_NS=y，且沒有對空間的使用做出限制），因此非特權用戶可以利用這個漏洞獲取root權限。以下所有的漏洞利用步驟都在用戶命名空間中完成。
Linux內核支持某些增強功能，會導致漏洞利用更加困難。KASLR（Kernel Address Space Layout Randomization，內核地址空間布局隨機化）機制會將內核文本（kernel text）存放到一個隨機的偏移地址，使得攻擊者無法通過跳轉到特定的固定地址完成攻擊；每當內核試圖從用戶空間內存執行代碼時，SMEP（Supervisor Mode Execution Protection，監督模式執行保護）機制就會觸發內核的oops錯誤；每當內核試圖直接訪問用戶空間的內存時，SMAP（Supervisor Mode Access Prevention，監督模式訪問防護）機制也能起到同樣效果。
6.1 堆操作
漏洞的利用思路是利用堆越界寫入bug，覆蓋內存中與溢出內存塊臨近的那個函數指針。因此我們需要對堆進行精確處理，使得某些帶有可觸發函數指針的對象被精確放置在某個環形緩沖區之后。我選擇前文提到的packet_sock結構體對象作為這類對象。我們需要找到一種辦法，使得內核將一個環形緩沖區內存塊和一個packet_sock對象緊緊分配在一起。
正如我前文提到的那樣，環形緩沖區內存塊通過內核頁面分配器進行分配。內核頁面分配器可以為內存塊分配2^n個連續的內存頁面。對于每個n值，分配器會為這類內存塊維護一個freelist表，并在請求內存塊時返回freelist表頭。如果某個n值對應的freelist為空，分配器就會查找第一個滿足m>n且其freelist不為空的值，然后將freelist分為兩半，直到所需的大小得到滿足。因此，如果我們開始以2^n大小重復分配內存塊，那么在某些時候，這些內存塊會由某個高位內存塊分裂所得，且這些內存塊會彼此相鄰。
packet_sock對象通過slab分配器使用kmalloc()函數進行分配。slab分配器主要用于分配比單內存頁還小的那些對象。它使用頁面分配器分配一大塊內存，然后切割這塊內存，生成較小的對象。大的內存塊稱之為slabs，這也就是slab分配器的名稱來源。一組slabs與它們的當前狀態以及一組操作(如“分配對象”操作，以及“釋放對象”操作)一起，統稱為一個緩存（cache）。slab分配器會按照2^n大小，為對象創建一組通用的緩存。每當kmalloc(size)函數被調用時，slab分配器會將size調整到與2的冪最為接近的一個值，使用這個size作為緩存的大小。
由于內核一直使用的都是kmalloc()函數，如果我們試圖分配一個對象，那么這個對象很大的可能會來自于之前已經創建的一個slab中。然而，如果我們開始分配同樣大小的對象，那么在某些時候，slab分配器將會將同樣大小的slab全部用光，然后不得不使用頁面分配器分配另一個slab。
新創建的slab的大小取決于這個slab所用的對象大小。packet_sock結構體的大小大約為1920，而1024 < 1920 <= 2048，這意味著對象的大小會調整到2048，并且會使用kmalloc-2048緩存。對于這個特定的緩存，SLUB分配器（這個分配器是Ubuntu所使用的slab分配器）會使用大小為0x8000的slabs。因此每當分配器用光kmalloc-2048緩存的slab時，它就會使用頁面分配器分配0x8000字節的空間。
了解這些知識后，我們就可以將一個kmalloc-2048的slab和一個環形緩沖區內存塊分配在一起，使用如下步驟：
1、分配許多大小為2048的對象（對我來說512個就可以），填充當前kmalloc-2048緩存中存在的slabs。我們可以創建一堆數據包套接字來分配packet_sock對象，最終達到這個目的。
2、分配許多大小為0x8000的頁面內存塊（對我來說1024個就可以），擠掉頁面分配器的freelists，使得某些高位頁面內存塊被拆分。我們可以創建另一個數據包套接字，將具有1024個大小為0x8000的內存塊的環形緩沖區附加在其后，最終達到這個目的。
3、創建一個數據包套接字，并附加一個內存塊大小為0x8000的環形緩沖區。最后一個內存塊（我總共使用了2個內存塊，原因在下面解釋）就是我們需要溢出的那個內存塊。
4、創建一堆數據包套接字來分配packet_sock結構體對象，最終導致至少有一個新的slab被分配。
這樣我們就可以對堆進行精確操作，如下圖所示：
為了排擠freelists、按照上述方法精確操作堆，我們需要分配的具體數量會根據設置的不同以及內存使用情況的不同而有所不同。對于一個大部分時間處于空閑狀態的Ubuntu主機來說，使用我上面提到的個數就以足夠。
6.2 控制覆蓋操作
上面我提到過，這個bug會導致某個環形緩沖區內存塊的越界寫入，我們可以控制越界的偏移量，也可以控制寫入數據的最大值。事實證明，我們不僅能夠控制最大值和偏移量，我們實際上也能控制正在寫入的精確數據（及其大小）。由于當前正在存放到環形緩沖區中的數據為正在通過特定網絡接口的數據包，我們可以通過回環接口，使用原始套接字手動發送具有任意內容的數據包。如果我們在一個隔離的網絡命名空間中執行這個操作，我們就不會受到外部網絡流量干擾。
此外我們還需要注意其他一些事項。
首先，數據包的大小至少必須為14字節（兩個mac地址占了12字節，而EtherType占了2個字節），以便傳遞到數據包套接字層。這意味著我們必須覆蓋至少14字節的數據，而數據包本身的內容可以取任意值。
其次，出于對齊目的，nxt_offset的最低3個比特必須取值為2。這意味著我們不能在8字節對齊的偏移處開始執行覆蓋操作。
再者，當數據包被接收然后保存到內存塊中時，內核會更新內存塊和幀頭中的某些字段。如果我們將nxt_offset指向我們希望覆蓋的某些特定偏移處，那么內存塊和幀頭結束部位的某些數據很有可能會被破壞。
另一個問題就是，如果我們將nxt_offset指向內存塊的尾部，那么當第一個數據包正在接收時，第一個內存塊會馬上被關閉，這是因為內核會認為第一個內存塊中沒有任何空余的空間（這是正確的處理流程，可以參考__packet_lookup_frame_in_block()函數中的代碼片段）。這不是一個真正的問題，因為我們可以創建一個具備2個內存塊的環形緩沖區。在第一個內存塊被關閉時，我們可以覆蓋第二個內存塊。
6.3 執行代碼
現在，我們需要弄清楚我們需要覆蓋哪個函數指針。在packet_sock結構體中，有一些函數指針字段，我最終使用了如下兩個字段：
1、packet_sock->xmit；
2、packet_sock->rx_ring->prb_bdqc->retire_blk_timer->func
每當用戶嘗試使用數據包套接字發送數據包時，就會調用第一個函數。提升到root權限的通常方法是在某個進程上下文中執行commit_creds(prepare_kernel_cred(0))載荷。對于第一個函數，進程上下文中會調用xmit指針，這意味著我們可以簡單地將其指向一個包含載荷的可執行內存區域就能達到目的。
因此，我使用的是retire_blk_timer字段（Philip Pettersson在他發現的CVE-2016-8655漏洞中也利用了這個字段）。這個字段包含一個函數指針，每當計時器超時時就會觸發這個指針。在正常的數據包套接字操作過程中，retire_blk_timer->func指向的是prb_retire_rx_blk_timer_expired()，調用這個函數時會使用retire_blk_timer->data作為參數，這個參數中包含了packet_sock結構體對象的地址。由于我們可以一起覆蓋函數字段和數據字段，因此我們可以獲得一個非常完美的func(data)覆蓋結果。
當前CPU核心的SMEP和SMAP狀態由CR4寄存器的第20和21個比特位所控制。為了禁用這兩個機制，我們應該將這兩個比特位清零。為了做到這一點，我們可以使用前面獲得的func(data)結果調用native_write_cr4(X)函數，其中X的第20和21個比特位設置為0。具體的X值可能取決于還有哪些CPU功能被啟用。在我測試漏洞利用的那臺機器上，CR4寄存器的值為0x10407f0（因為CPU不支持SMAP功能，因此只有SMEP比特被啟用），因此我使用的X值為0x407f0。我們可以使用sched_setaffinity系統調用，強迫漏洞利用程序在某個CPU核心上運行，由于這個我們禁用了這個核心的SMAP和SMEP功能，這樣一來就能確保用戶空間載荷會在同一個核心上執行。
綜合這些背景知識，我給出了如下的漏洞利用步驟：
1、找到內核文本地址，以繞過KASLR（具體方法參考下文描述）。
2、根據上文描述，操縱內核堆。
3、禁用SMEP和SMAP：
a) 在某個環形緩沖區內存塊之后分配一個packet_sock對象；
b) 將一個接收環形緩沖區附加到packet_sock對象之后，以設置一個內存塊停用計時器；
c) 溢出這個內存塊，覆蓋retire_blk_timer字段。使得retire_blk_timer->func指向native_write_cr4，并且使得retire_blk_timer->data的值與所需的CR4寄存器值相等；
d) 等待計時器執行，現在我們就可以在當前的CPU核心上禁用SMEP和SMAP了。
4、獲取root權限。
a) 分配另一對packet_sock對象和環形緩沖區內存塊。
b) 溢出這個內存塊，覆蓋xmit字段。使得xmit指向用戶空間中分配的一個commit_creds(prepare_kernel_cred(0))函數。
c) 在對應的數據包套接字上發送一個數據包，xmit就會被觸發，然后當前的進程就會獲得root權限。
相應的漏洞利用代碼可以在這個鏈接中找到。
需要注意的是，當我們覆蓋packet_sock結構體中的這兩個字段時，我們最終會破壞在這兩個字段之前的某些字段（因為內核會將某些值寫入內存塊和幀頭中），這可能會導致內核崩潰。然而，如果其他這些字段沒有被內核使用，那么一切都還好。我發現當我們在漏洞利用結束后，嘗試關閉所有的數據包套接字時，mclist這個字段會導致內核崩潰，但我們只要將其清零即可。
6.4 繞過KASLR
在這里我會介紹某些精心構造的技術，來繞過KASLR機制。由于Ubuntu默認情況下不會限制dmesg，我們可以使用grep命令，查找內核syslog日志中的“Freeing SMP“關鍵詞，我們可以在結果中找到一個內核指針，看起來與內核文本地址非常相似，如下所示：
| 1 2 3 4 5 6 7 8 9 10 | #?Boot?#1 $?dmesg?|?grep?'Freeing?SMP' [????0.012520]?Freeing?SMP?alternatives?memory:?32K?(ffffffffa58ee000?-?ffffffffa58f6000) $?sudo?cat?/proc/kallsyms?|?grep?'T?_text' ffffffffa4800000?T?_text #?Boot?#2 $?dmesg?|?grep?'Freeing?SMP' [????0.017487]?Freeing?SMP?alternatives?memory:?32K?(ffffffff85aee000?-?ffffffff85af6000) $?sudo?cat?/proc/kallsyms?|?grep?'T?_text' ffffffff84a00000?T?_text |
在dmesg中暴露的地址的基礎上，通過簡單的數學運算，我們可以計算出內核文本地址。使用這種方式計算出來的內核文本地址只有在啟動之后的一段時間內有效，因為syslog只存儲固定行數的這類日志，然后在某些時候抹掉這些日志。
我們可以使用幾個Linux內核加固功能來避免這類信息泄露。第一個功能是dmesg_restrict，它可以限制非特權用戶讀取內核syslog日志。需要注意的是，即使在受限dmesg下，Ubuntu的第一個用戶還是可以從“/var/log/kern.log”以及“/var/log/syslog”處讀取syslog日志，因為該用戶隸屬于adm用戶組。
另一個功能是kptr_restrict，這個功能不允許非特權用戶查閱內核使用“%pK”格式說明符打印的指針。然而，在4.8版內核中，free_reserved_area()函數使用的是“%p”格式符，因此這種情況下kptr_restrict不會發揮作用。4.10版內核中修復了free_reserved_area()函數，這個函數根本就不會打印地址范圍，但這個修改沒有做到向前兼容。
七、修復措施
我們來看看補丁原理。修復前的漏洞代碼如下所示。請記住，用戶可以完全控制tp_block_size和tp_sizeof_priv字段：
| 1 2 3 4 | 4207?????????????????if?(po->tp_version?>=?TPACKET_V3?&& 4208?????????????????????(int)(req->tp_block_size?- 4209???????????????????????????BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv))?<=?0) 4210?????????????????????????goto?out; |
在考慮如何修復這個漏洞時，我們想到的第一個思路就是，我們可以比較這兩個值，避免這些值被轉化為非預期的整數（int）：
| 1 2 3 4 | 4207?????????????????if?(po->tp_version?>=?TPACKET_V3?&& 4208?????????????????????req->tp_block_size?<= 4209???????????????????????????BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv)) 4210?????????????????????????goto?out; |
有趣的是，這個修復措施并不會奏效。原因在于當tp_sizeof_priv接近于unsigned int的最大值時，在處理BLK_PLUS_PRIV時還是會出現溢出問題。
| 1 2 | 177?#define?BLK_PLUS_PRIV(sz_of_priv)?\ 178?????????(BLK_HDR_LEN?+?ALIGN((sz_of_priv),?V3_ALIGNMENT)) |
修改這個溢出問題的一種辦法就是在將tp_sizeof_priv傳遞給BLK_PLUS_PRIV之前，將其轉化為uint64類型值。這就是我在上游代碼中做的修復措施：
| 1 2 3 4 | 4207?????????????????if?(po->tp_version?>=?TPACKET_V3?&& 4208?????????????????????req->tp_block_size?<= 4209???????????????????????????BLK_PLUS_PRIV((u64)req_u->req3.tp_sizeof_priv)) 4210?????????????????????????goto?out; |
八、緩解措施
我們需要CAP_NET_RAW權限才能創建數據包套接字，非特權用戶可以在用戶命名空間中獲取這個權限。非特權用戶命名空間暴露了許多內核攻擊面，這最終導致了許多可利用的漏洞（如CVE-2017-7184、CVE-2016-8655等）。我們可以通過完全禁用用戶命名空間或者禁止非特權用戶使用這類空間來緩解這類內核漏洞。
要徹底禁用用戶命名空間，你可以在禁用CONFIG_USER_NS的條件下，重新編譯自己的內核。在基于Debian的內核中，我們可以將/proc/sys/kernel/unprivileged_userns_clone的值設為0，以限制只有特權用戶才能使用用戶命名空間。從4.9版內核起，上游內核中就具有類似的“/proc/sys/user/max_user_namespaces”設置。
九、總結
就目前而言，（從安全角度來看）Linux內核中存在大量沒有經過完善測試的接口，其中很多接口在諸如Ubuntu等流行的Linux發行版中處于啟用狀態，并且向非特權用戶開放。這種現象顯然是不好的，我們需要好好測試或者進一步限制這些接口。
Syzkaller是個令人驚奇的工具，允許我們對內核接口進行模糊測試。我們甚至可以為其他系統調用添加準系統（barebone）描述信息，這樣通常也能發現許多bug。由于內核中還有許多地方沒有覆蓋到（可能會有一大堆安全漏洞存在于內核中），我們因此也需要大家一起協作，編寫系統調用描述信息，對已有的問題進行修復。我們非常樂意看到讀者通過發起代碼的pull請求，貢獻自己的一份力。
十、參考鏈接
相應的參考鏈接為：
利用代碼：
https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-7308?
修復代碼：
https://github.com/torvalds/linux/commit/2b6867c2ce76c596676bec7d2d525af525fdc6e2?
CVE編號：
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7308?
我們用來查找Linux內核錯誤的工具為：
syzkaller：https://github.com/google/syzkaller?
KASAN：https://www.kernel.org/doc/html/latest/dev-tools/kasan.html?
KTSAN：https://github.com/google/ktsan/wiki?
KMSAN：https://github.com/google/kmsan
已整理的Linux內核漏洞利用資料：?
https://github.com/xairy/linux-kernel-exploitation?
原文地址：?http://bobao.360.cn/learning/detail/3885.html
總結
以上是生活随笔為你收集整理的如何通过数据包套接字攻击Linux内核的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android 破解之道 （二）
- 下一篇： Mips KVM TrapEmulate