發佈 Samba 的重大安全性漏洞,2016 年 4 月 12 日

Samba 是 SMB(Server Message Block)開放原始碼或 CIFS(Common Internet File System)的開放原始碼版本,能讓 PC 相容的機器來分享檔案、印表機及其他資訊。我們在所有支援的 Samba 中,發現了幾個漏洞。欲知這名為 Badlock 問題的資訊(CVE-2016-2118),請參閱知識庫文章2253041

受影響的版本:

CVE RHEL 5 samba RHEL 5 samba3x RHEL 6 samba RHEL 6 samba4 RHEL 7 Gluster Storage 受影響的 Samba 角色
CVE-2015-5370 N Y Y Y Y Y 所有 Samba 能操作的可能角色
CVE-2016-2110 Y Y Y Y Y Y 所有 Samba 能操作的可能角色
CVE-2016-2111 Y Y Y Y Y Y 標準主 DC、備用 DC 或 Active Directory DC
CVE-2016-2112 Y Y Y Y Y Y 所有 Samba 能操作的可能角色
CVE-2016-2113 N N N Y Y Y 所有 Samba 能操作的可能角色
CVE-2016-2114 N N N Y Y Y 所有 Samba 能操作的可能角色
CVE-2016-2115 Y Y Y Y Y Y 所有 Samba 能操作的可能角色
CVE-2016-2118 Y Y Y Y Y Y 所有 Samba 能操作的可能角色,且對 Active Directory DC 來說是重大的角色

CVE-2015-5370:DCE/RPC 程式碼中的多重漏洞

Samba 的 DCE/RPC 通訊協定中有幾個漏洞。來自遠端、通過身分認證的攻擊者可以使用這些漏洞
Samba 伺服器進行 DoS(阻斷服務)攻擊(造成高 CPU 負載或當機),或透過執行 Samba 的使用者(root)之權限來執行任何程式碼。這漏洞也可以透過中間人攻擊(man-in-the-middle)來取得 AD(Active Directory)的控制權、並侵入 Samba AD DC(Domain Controller)的安全性,將安全的 DCE/RPC 連線降級。

注意:有鑑於 RHEL(Red Hat Enterprise Linux)的 Samba 套件並不支援將 Samba 執行為 AD DC,因此這漏洞會套用到所有 Samba 所實作的角色。

CVE-2016-2118 (Badlock):SAMR 與 LSA 可能會引起中間人攻擊

關於此漏洞的詳細資料可以在此找到:Samba 的 Badlock 安全性漏洞 - CVE-2016-2118

CVE-2016-2110:使用 NTLMSSP 時的中間人攻擊

Samba 對於 NTLMSSP 身分認證的實作部分,有幾個漏洞。未經授權、使用中間人攻擊的攻擊者可以使用這漏洞來清除連線的加密與完整性旗標,導致資料以一般文字方式傳送。攻擊者也可以強迫用戶端或伺服器端以一般文字傳送資料,不管連線是否已選擇使用加密。

多種管理性的 Samba 專案工具(例如 net、samba-tool、ldbsearch 或 ldbedit)會使用 LDAP(使用 NTLMSSP 身分認證)。

這些漏洞會影響所有 Samba 能操作的角色,並與CVE-2016-2112CVE-2016-2113相關。

CVE-2016-2111:NETLOGON 偽冒弱點

我們發現 Samba 作為 DC 時,可能會與使用偽冒電腦名稱的機器建立安全連線。能觀察網路交通的遠端攻擊者可以透過這漏洞,取得偽冒機器的 session 之相關資訊。

這弱點只會影響作為傳統主 DC、備用 DC 或 AC DC 的 Samba。

這漏洞屬於 Microsoft Windows Server 的 CVE-2015-0005

此漏洞的安全升級檔是以新的 smb.conf 選項來完成:

  raw NTLMv2 auth (G)

    這參數會決定 smbd(8) 是否允許 SMB1 用戶端
    不管延伸安全性(沒有 SPNEGO)是不是要使用 NTLMv2 身分認證。

    如果這選項,lanman auth,以及 ntlm auth 都停用了,那麼只有
    支援了 SPNEGO 的用戶端允許使用。這表示 NTLMv2 僅
    在 NTLMSSP 中受到支援。

    預設值:raw NTLMv2 auth = no

CVE-2016-2112:LDAP 用戶端與伺服器端並不會強制完整性防護

我們發現 Samba 的 LDAP 並不會為 LDAP 連線強制使用完整性防護。中間人攻擊可以使用此漏洞,將 LDAP 連線降級至不使用完整性防護,讓攻擊者劫持這類連線。

這漏洞會影響所有Samba 可以操作的所有角色。

此漏洞的安全升級檔是以新的 smb.conf 選項來完成:

  ldap server require strong auth (G)

    "ldap server require strong auth" 選項定義了
    ldap 伺服器 ldap 交通是否需要簽署或
    簽署暨加密(簽章)。可能的值為 no、
    allow_sasl_over_tls 與 yes。

    在所有傳輸上不允許簡單與 sasl 連結的值。

    allow_sasl_over_tls 值能讓允許簡單與 sasl 連結(沒有簽署或簽章)
    在 TLS 加密連線上。未加密的連線僅
    允許 sasl 使用簽署或簽章來連結。

    設為 yes 僅允許透過 TLS 加密連線來進行簡單連結。
    未加密的連線僅允許 sasl 透過簽署與簽章來連結。

    預設值:ldap server require strong auth = yes

注意:LDAP 伺服器還沒有選項來強制使用強的身分認證。安全性升級檔會引介新的選項,稱為 ldap server require strong auth,可用的值包括 noallow_sasl_over_tlsyes

預設行為之前設為 no,在所有用戶端調整以處理 LDAP_STRONG_AUTH_REQUIRED 錯誤之前,使用者可能得特意變更這選項。Windows 用戶端與 Samba 成員伺服器已經使用了完整性防護。

CVE-2016-2113:缺乏 TLS/SSL 憑證的驗證會引起中間人攻擊

我們發現,在一些連線中,Samba 並不會驗證 SSL/TLS 憑證。中間人攻擊會使用這弱點,使用特別打造的 SSL/TLS 憑證來偽冒 Samba 伺服器。

這漏洞會影響所有Samba 可以操作的所有角色。

此漏洞的安全升級檔是以新的 smb.conf 選項來完成:

  tls verify peer (G)

    這會控制用戶端是否、且多嚴格驗證其它用戶端
    的憑證與名稱。可用的值(升冪排序)是:no_check、
    ca_only、ca_and_name_if_available、ca_and_name 與 as_strict_as_possible。

    設定為 no_check 時,完全不驗證憑證,
    會引起中間人攻擊。

    設為 ca_only 時,會驗證來自 CA 的憑證,這
    指定於 "tls ca file" 選項中。設定 "tls ca file" 時,驗證檔案
    是必須的。憑證的過期日也會被驗證。如果設置了 "tls crl file"
    選項,憑證也會透過
    CA CRL 來驗證。

    設為 ca_and_name_if_available 時,會進行所有來自 ca_only 的檢查。
    除此之外,同儕的主機名稱會與憑證
    名稱驗證,如果這是由應用層所提供,並不是以
    IP 位址的字串所提供。

    設為 ca_and_name 時,會進行所有來自 ca_and_name_if_available 的檢查。
    除此之外,這需要提供同儕的主機名稱,即使 IP
    位址已經透過驗證名稱檢查。

    設為 as_strict_as_possible 時,會進行所有來自 ca_and_name 的檢查。
    除此之外,"tls crl file" 需要被配置。未來版本的
    Samba 可能會有額外的檢查。

    預設值:tls verify peer = as_strict_as_possible

CVE-2016-2114:"server signing = mandatory" 並非強制

我們發現 Samba 並未強制使用 SMB(Server Message Block)簽署功能給使用 SMB1 通訊協定的用戶端使用。中間人攻擊可以使用這弱點,修改用戶端與伺服器端的交通。

這弱點會影響以下伺服器角色:獨立伺服器、成員伺服器、傳統主 DC、備用 DC、以及 AD DC。

減緩問題:

smb.conf 檔案中 [global] 一節所指定的 server signing = mandatory 配置選項與 server min protocol = SMB2 應該可以避免不使用簽署保護就進行連線。然而,這可能會導致舊的、不支援 SMB2 以上的用戶端無法連線。

CVE-2016-2115:SMB 用戶端連線的 IPC 交通並沒有完整性防護

我們發現 Samba 預設上並沒有為 IPC 交通啟用完整性防護。中間人攻擊者可以使用此弱點來檢視、修改 Samba 伺服器與客戶端之間傳遞的資料。

此漏洞的安全升級檔是以幾個新的 smb.conf 選項來完成:

  client ipc signing (G)

    這會控制用戶端是否允許或需要使用
    SMB 簽署給 IPC$ 連線用,作為 DCE/RPC 傳輸。可用的
    值有 auto、mandatory 與 disabled。

    設為 mandatory 或 default 時,會需要 SMB 簽署。

    設定為 auto 時,會提供 SMB 簽署,但並不會強制,且
    如果設為 disabled,就不會提供 SMB 簽署。

    從 winbindd 連至 AD DC 的連線
    會強制使用簽署。

    預設值:client ipc signing = default

  client ipc max protocol (G)

    參數值(字串)是最高的通訊協定等級
    用在 IPC$ 連線上,作為 DCE/RPC 傳輸。

    正常來說,這個選項不該設定,因為 SMB 通訊協定的
    自動協調過程會負責選擇適當的通訊協定。

    default 這個值指向最新的受支援通訊協定,目前是  SMB3_11。

    欲知可用通訊協定的完整清單,請參閱 client max protocol。
    CORE、COREPLUS、LANMAN1、LANMAN2 值已被默默更新至 NT1。
   預設值:client ipc max protocol = default

    範例:client ipc max protocol = SMB2_10

  client ipc min protocol (G)

    這項設定會控制最小通訊協定版本,
    試圖使用 IPC$ 通訊作為 DCE/RPC 傳輸。

    正常來說,這個選項不需設定,因為 SMB 通訊協定的
    自動協調過程會負責選擇適當的通訊協定。

    default 這個值指向 NT1 的最高版本,以及
    "client min protocol" 的有效值。

    欲知可用通訊協定的完整清單,請參閱 client max protocol。
    CORE、COREPLUS、LANMAN1、LANMAN2 值已被默默更新至 NT1。

    預設值:client ipc min protocol = default

    範例:client ipc min protocol = SMB3_11

減緩問題:

smb.conf 檔案中 [global] 一節所指定的 client signing = mandatory 配置選項與 server min protocol = SMB2

這漏洞會影響所有Samba 可以操作的所有角色。

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.