本文將重點介紹如何解決與第三方庫相關的問題

• 不能被規避
• 難以排除/繞過/替換
• 只需不提供錯誤修正

在這種情況下，解決問題仍然是一項艱巨的任務。

作為這種情況的誘因，請考慮對“哈希索引”數據結構的攻擊，例如java.util.Hashtable和java.util.HashMap （對于不熟悉此類攻擊的人，我建議查看以下內容28C3： 對Web應用程序進行拒絕服務攻擊變得容易（ ）。

長話短說，核心問題是使用非加密哈希函數（在其中查找沖突很容易）。 根本原因隱藏在java.lang.String.hashCode（）函數中。 顯而易見的方法是修補java.lang.String類，這很困難，原因有兩個：

1. 它包含本機代碼
2. 它屬于Java核心類，這些Java核心類隨Java安裝一起提供，因此不受我們的控制

第一點將迫使我們修補體系結構和特定于OS的庫，我們應該在可能的情況下規避這些庫。 第二點是正確的，但是它會更靈活一些，我們將在下面看到。

好的，讓我們重新考慮：修補本機很臟，我們不急于采用這種方式–我們必須為不愿意修復其代碼的其他人（在本例中為SDK SDK庫）做一些工作。

嘗試：
哈希問題涉及到java.util.Hashtable和java.util.HashMap類，它們不使用任何本機代碼。 修補這些類非常容易，因為足以為所有體系結構和OS提供一個編譯的類。 我們可以使用提供的錯誤解決方案之一，并用固定版本調整（或替換）原始類。 困難在于在不接觸核心庫的情況下修補VM –我想如果用戶必須更改其JVM安裝的一部分，或者更糟糕的是，我們的應用程序在安裝過程中自動執行此操作，用戶將非常失望。 在某些情況下，進一步引入新的自定義類加載器可能會很困難。

我們需要的是一種動態修補我們的單個應用程序的解決方案–替換有問題的類，不要碰其他任何東西。 如果我們透明地執行此操作，則其他軟件部件甚至都不會識別任何更改（在最佳情況下），并保持與類的接口，而無需進行任何修改。

可以通過濫用Java Instrumentation API輕松地完成此操作。 引用JavaDoc ：

這正是我們所需要的！

概念證明
首先，我們需要一個示例應用程序來演示該概念：

public class StringChanger {public static void main(String[] args) {System.out.println(A.shout());}}public class A {public static String shout() {return "A";}
}

運行此類時，它僅輸出：A
應用我們的“補丁”之后，我們希望獲得以下輸出：已補丁

“修補的代碼如下所示：

public class A {public static String shout() {return "Apatched";}
}

進一步，我們需要一個“代理”來管理所使用的類并修補正確的類：

final public class PatchingAgent implements ClassFileTransformer {private static byte[] PATCHED_BYTES;private static final String PATH_TO_FILE = "Apatched.class";private static final String CLASS_TO_PATCH = "stringchanger/A";public PatchingAgent() throws FileNotFoundException, IOException {if (PATCHED_BYTES == null) {PATCHED_BYTES = readPatchedCode(PATH_TO_FILE);}}public static void premain(String agentArgument,final Instrumentation instrumentation) { System.out.println("Initializing hot patcher...");PatchingAgent agent = null;try {agent = new PatchingAgent();} catch(Exception e) {System.out.println("terrible things happened....");}instrumentation.addTransformer(agent);}@Overridepublic byte[] transform(final ClassLoader loader, String className,final Class classBeingRedefined, final ProtectionDomain protectionDomain,final byte[] classfileBuffer) throws IllegalClassFormatException {byte[] result = null;if (className.equals(CLASS_TO_PATCH)) {System.out.println("Patching... " + className);result = PATCHED_BYTES;}return result;}private byte[] readPatchedCode(final String path)throws FileNotFoundException, IOException {...}
}

不用擔心–我不會在實施細節上打擾您，因為這只是PoC代碼，遠非完美，巧妙，快速而簡潔。 除了我因為此時太懶而趕上 Exception以外，我不過濾輸入，構建深拷貝（防御性編程作為流行語），這實際上不應被視為生產代碼。

公共PatchingAgent（）
初始化代理（在這種情況下，將獲取修補的A.class文件的字節。修補的類已編譯并存儲在我們可以訪問它的位置。

公共靜態無效premain（…）
在JVM初始化并準備代理后，將調用此方法。

公共字節[]變換（…）
每當定義一個類時（例如，通過ClassLoader.defineClass （…）），該函數都將被調用，并且可以轉換已處理的類字節 []（ classfileBuffer ）。 可以看出，我們將為stringchanger包中的A類執行此操作。 您不受限制如何轉換類（只要它仍然是有效的Java 類 ）–例如，您可以利用字節碼修改框架…–為使事情簡單，我們假設我們將舊字節 []替換為修補的類之一（只需將完整的修補A.class文件緩存到字節 []中）。

這就是修補程序編碼部分的全部內容……最后，我們必須用一個特殊的manifest.mf文件構建一個jar容器，該文件告訴JVM如何調用該代理。

清單版本：1.0
X-COMMENT：Main-Class將通過構建自動添加
Premain-Class：stringchanger.PatchingAgent

構建完這個jar之后，我們可以嘗試PoC應用程序。 首先，我們將在沒有調用代理的必要JVM參數的情況下調用它：

跑：
一個
建立成功（總時間：0秒）

它的行為符合預期，并輸出未修補類定義的輸出。

現在，我們將使用神奇的JVM參數來嘗試調用代理-javaagent：StringChanger.jar：

跑：
初始化熱補丁程序…
讀取修補文件。 修補…換弦器/ A 已分配 建立成功（總時間：0秒）

Voilà，該代碼已成功進行了實時修補！

如我們所見，可以動態地對JVM進行熱補丁而不用觸摸交付的代碼。 必須要做的是開發修補程序和修補的類。 目前，我還不了解性能評估數據。 因此，我不確定該解決方案對生產系統的實用性以及對應用程序性能的影響程度。

明確地說，這不是一個優雅的解決方案–至少它很臟！ 最好的方法是修補根本原因，但只要沒有供應商修復程序，開發人員就可以通過熱修補來防止其軟件運行，而無需重寫使用易受攻擊類的每一行。

最后，我希望提出意見，改進或只是更好的解決方案。 非常感謝Juraj Somorovsky與我在這個問題上共同努力。

參考： JCG合作伙伴 在運行時修補Java ? Christopher Meyer討論了Java安全性和相關主題 。