如何進行libssh2整形溢出漏洞CVE-2019-17498分析

這期內容當中小編將會給大家帶來有關如何進行libssh2整形溢出漏洞CVE-2019-17498分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

嚴重性與緩解方案

   該漏洞并不是一個Openssh漏洞，所以它不會影響ssh。Libssh3是一個客戶端C代碼庫，它能夠幫助應用程序與SSH服務器建立連接。而且該漏洞也不是一個libssh漏洞，因為libssh并非C代碼庫，只不過它的功能跟libssh3類似而已。

該漏洞存在于libssh3 v1.9.0及更早版本之中，目前該漏洞已經在libssh3的master分支成功修復，但是官方并沒有發布包含漏洞修復方案的正式版。

該漏洞涉及到越界讀取的問題，并有可能導致目標服務出現拒絕服務或遠程信息披露的風險。當libssh3被用來跟惡意SSH服務器建立連接時，便有可能觸發該漏洞。當SSH服務器發送一條斷開連接消息時，便會發生溢出。這也就意味著，該漏洞可以在連接過程的開始階段，及身份認證完成之前被觸發。

觸發漏洞

該漏洞的原始位置位于packet.c：480處：

if(message_len < datalen-13) {

datalen的值是一個不受信的值，它由遠程SSH服務器控制。如果datalen==11，那么減法運算將會發生溢出，針對message_len的越界檢測將會失效。Message_len是一個無符號的32位整型，它的值同樣由遠程SSH服務器控制，所以這將導致第485行代碼發生越界讀取：

language_len =_libssh3_ntohu32(data + 9 + message_len);

越界讀取通常來說會導致分段錯誤，但是本文所描述的問題將有可能導致代碼調用第499行的LIBSSH2_DISCONNECT：

if(session->ssh_msg_disconnect) {    LIBSSH2_DISCONNECT(session, reason, message,                       message_len, language, language_len);}

具體情況取決于libssh3庫是如何被使用的，因為session->ssh_msg_disconnect是一個回調函數，默認為NULL，但是用戶也可以通過調用libssh3_session_callback_set來自行設置。

我在這里專門寫了一個漏洞利用PoC：【點我獲取】。它模擬了一個惡意SSH服務器，可以返回包含datalen==11和message_len==0x41414141的斷開連接消息，這將導致libssh3出現分段錯誤并發生崩潰。

Liibssh3整型溢出變種分析

當我在將一個安全漏洞報告給廠商時，我通常會在報告中包含兩個內容：

1、漏洞的漏洞利用代碼PoC；

2、QL查詢，識別所有我認為需要修復的代碼位置；

在PoC中包含QL查詢，個人認為有以下好處：

1、如果代碼包含多個相似的漏洞，那么我們就可以編寫一個查詢請求來枚舉它們。

2、QL查詢可以幫助我快速判斷漏洞是否成功被修復。

3、QL查詢可以將結果以單獨URL的形式呈現給我，便于我們進行后續分析。

創建一個PoC通常涉及到大量的工作，如果某個目標存在多個非常相似的漏洞，那我一般會針對其中一個漏洞寫一個PoC，因為一個PoC足以證明漏洞的影響了。這個查詢的目的并不是找到libssh3中所有的整形溢出漏洞，它的主要目的是找出該PoC觸發的漏洞以及其他的相似變種。

Semmle QL查詢代碼如下：

/** * @kind path-problem */import cppimport semmle.code.cpp.rangeanalysis.SimpleRangeAnalysisimport semmle.code.cpp.dataflow.TaintTrackingimport DataFlow::PathGraphclass Config extends DataFlow::Configuration {  Config() { this = "_libssh3_ntohl bounds check overflow" }  override predicate isSource(DataFlow::Node source) {    source.asExpr().(FunctionCall).getTarget().getName().matches("_libssh3_ntoh%")  }  override predicate isSink(DataFlow::Node sink) {    convertedExprMightOverflowNegatively(sink.asExpr()) and    exists(RelationalOperation cmp | cmp.getAnOperand() = sink.asExpr())  }  override predicate isAdditionalFlowStep(DataFlow::Node source,                                          DataFlow::Node target) {    exists(Field f |      source.asExpr() = f.getAnAssignedValue() and      target.asExpr() = f.getAnAccess())    or    target.asExpr().(AddExpr).getAnOperand() = source.asExpr()    or    target.asExpr().(SubExpr).getAnOperand() = source.asExpr()  }}from Config cfg, DataFlow::PathNode source, DataFlow::PathNode sinkwhere cfg.hasFlowPath(source, sink)select sink, source, sink,  "possible integer overflow of tainted expression in bounds check"

其中，isSource表示尋找到了針對_libssh3_ntohu32和 _libssh3_ntohu64的調用，它們主要用來進行網絡至主機的字節順序轉義。這些函數一般都可以用來尋找那些“攻擊者控制的數據”。但是我這里使用的isSink目的是尋找對比暈眩，其中包含可能發生溢出的子表達式。比如說，message_len < datalen-13是一個比較表達式，而datalen-13則有可能發生溢出。我的查詢還會重寫isAdditionalFlowStep選項，并自定義數據流邊界集。

上述就是小編為大家分享的如何進行libssh2整形溢出漏洞CVE-2019-17498分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。