nippy/test/taoensso/nippy/tests/main.clj

326 lines
11 KiB
Clojure
Raw Normal View History

(ns taoensso.nippy.tests.main
(:require
2022-06-27 07:55:24 +00:00
[clojure.test :as test :refer [deftest testing is]]
[clojure.test.check :as tc]
[clojure.test.check.generators :as tc-gens]
[clojure.test.check.properties :as tc-props]
2022-06-27 07:55:24 +00:00
[taoensso.encore :as enc :refer []]
[taoensso.nippy :as nippy :refer [freeze thaw]]
[taoensso.nippy.benchmarks :as benchmarks]))
(comment (test/run-tests))
2014-02-23 11:52:50 +00:00
(def test-data nippy/stress-data-comparable)
(def tc-num-tests 120)
(def tc-gens
"Like `tc-gens/any` but removes NaN (which breaks equality tests)"
(tc-gens/recursive-gen tc-gens/container-type #_simple-type
(tc-gens/one-of
[tc-gens/int tc-gens/large-integer #_tc-gens/double
(tc-gens/double* {:NaN? false})
tc-gens/char tc-gens/string tc-gens/ratio tc-gens/boolean tc-gens/keyword
tc-gens/keyword-ns tc-gens/symbol tc-gens/symbol-ns tc-gens/uuid])))
(comment (tc-gens/sample tc-gens 10))
;;;; Core
(deftest _core
(is (do (println (str "Clojure version: " *clojure-version*)) true))
(is (= test-data ((comp thaw freeze) test-data)))
(is (= test-data ((comp #(thaw % {:no-header? true
:compressor nippy/lz4-compressor
:encryptor nil})
#(freeze % {:no-header? true}))
test-data)))
(is (= test-data ((comp #(thaw % {:password [:salted "p"]})
#(freeze % {:password [:salted "p"]}))
test-data)))
2020-07-24 17:38:16 +00:00
(is (= (vec (:objects nippy/stress-data))
((comp vec thaw freeze) (:objects nippy/stress-data))))
(is (= test-data ((comp #(thaw % {:compressor nippy/lzma2-compressor})
#(freeze % {:compressor nippy/lzma2-compressor}))
test-data)))
(is (= test-data ((comp #(thaw % {:compressor nippy/lzma2-compressor
:password [:salted "p"]})
#(freeze % {:compressor nippy/lzma2-compressor
:password [:salted "p"]}))
test-data)))
(is (= test-data ((comp #(thaw % {:compressor nippy/lz4-compressor})
#(freeze % {:compressor nippy/lz4hc-compressor}))
test-data)))
(is ; Try roundtrip anything that simple-check can dream up
(:result (tc/quick-check tc-num-tests
(tc-props/for-all [val tc-gens]
(= val (thaw (freeze val)))))))
(is (thrown? Exception (thaw (freeze test-data {:password "malformed"}))))
(is (thrown? Exception (thaw (freeze test-data {:password [:salted "p"]})
{;; Necessary to prevent against JVM segfault due to
;; https://goo.gl/t0OUIo:
:v1-compatibility? false})))
(is (thrown? Exception (thaw (freeze test-data {:password [:salted "p"]})
{:v1-compatibility? false ; Ref. https://goo.gl/t0OUIo
:compressor nil})))
(is ; Snappy lib compatibility (for legacy versions of Nippy)
(let [^bytes raw-ba (freeze test-data {:compressor nil})
^bytes xerial-ba (org.xerial.snappy.Snappy/compress raw-ba)
^bytes iq80-ba (org.iq80.snappy.Snappy/compress raw-ba)]
(= (thaw raw-ba)
(thaw (org.xerial.snappy.Snappy/uncompress xerial-ba))
(thaw (org.xerial.snappy.Snappy/uncompress iq80-ba))
(thaw (org.iq80.snappy.Snappy/uncompress iq80-ba 0 (alength iq80-ba)))
2020-07-24 17:38:16 +00:00
(thaw (org.iq80.snappy.Snappy/uncompress xerial-ba 0 (alength xerial-ba))))))
(is ; CBC auto-encryptor compatibility
(= "payload"
(thaw (freeze "payload" {:password [:salted "pwd"] :encryptor nippy/aes128-cbc-encryptor})
(do {:password [:salted "pwd"]})))))
;;;; Custom types & records
2013-08-06 16:56:43 +00:00
(deftype MyType [basic_field fancy-field!]) ; Note `fancy-field!` field name will be munged
(defrecord MyRec [basic_field fancy-field!])
(deftest _types
2022-06-27 07:55:24 +00:00
(testing "Extend to custom type"
(is
(thrown? Exception ; No thaw extension yet
(do
(alter-var-root #'nippy/*custom-readers* (constantly {}))
(nippy/extend-freeze MyType 1 [x s]
(.writeUTF s (.basic_field x))
(.writeUTF s (.fancy-field! x)))
(thaw (freeze (MyType. "basic" "fancy"))))))
2022-06-27 07:55:24 +00:00
(is
(do
(nippy/extend-thaw 1 [s] (MyType. (.readUTF s) (.readUTF s)))
(let [mt1 (MyType. "basic" "fancy")
^MyType mt2 (thaw (freeze mt1))]
(=
[(.basic_field mt1) (.fancy-field! mt1)]
[(.basic_field mt2) (.fancy-field! mt2)])))))
2022-06-27 07:55:24 +00:00
(testing "Extend to custom Record"
(is
(do
(nippy/extend-freeze MyRec 2 [x s]
(.writeUTF s (str "foo-" (:basic_field x)))
(.writeUTF s (str "foo-" (:fancy-field! x))))
(nippy/extend-thaw 2 [s] (MyRec. (.readUTF s) (.readUTF s)))
(=
(do (MyRec. "foo-basic" "foo-fancy"))
(thaw (freeze (MyRec. "basic" "fancy")))))))
2022-06-27 07:55:24 +00:00
(testing "Keyword (prefixed) extensions"
(is
(do
(nippy/extend-freeze MyRec :nippy-tests/MyRec [x s]
(.writeUTF s (:basic_field x))
(.writeUTF s (:fancy-field! x)))
(nippy/extend-thaw :nippy-tests/MyRec [s] (MyRec. (.readUTF s) (.readUTF s)))
(let [mr (MyRec. "basic" "fancy")]
(= mr (thaw (freeze mr))))))))
2015-09-28 08:02:06 +00:00
;;;; Stable binary representation of vals
(deftest _stable-bin
(is (= (seq (freeze test-data))
(seq (freeze test-data)))) ; f(x)=f(y) | x=y
;; As above, but try multiple times to catch possible protocol interface races:
(is (every? true?
(repeatedly 1000 (fn [] (= (seq (freeze test-data))
(seq (freeze test-data)))))))
;; NB abandoning - no way to do this reliably w/o appropriate contracts from
;; (seq <unordered-coll>):
;;
;; (is (= (seq (-> test-data freeze))
;; (seq (-> test-data freeze thaw freeze)))) ; f(x)=f(f-1(f(x)))
;;
;; As above, but with repeated refreeze to catch possible protocol interface races:
;; (is (= (seq (freeze test-data))
;; (seq (reduce (fn [frozen _] (freeze (thaw frozen)))
;; (freeze test-data) (range 1000)))))
)
(defn qc-prop-bijection [& [n]]
(let [bin->val (atom {})
val->bin (atom {})]
(merge
(tc/quick-check (or n 1)
(tc-props/for-all [val tc-gens]
(let [;; Nb need `seq` for Clojure hash equality:
bin (hash (seq (freeze val)))]
(and
(if (contains? val->bin val)
(= (get val->bin val) bin) ; x=y => f(x)=f(y) by clj=
(do (swap! val->bin assoc val bin)
true))
(if (contains? bin->val bin)
(= (get bin->val bin) val) ; f(x)=f(y) => x=y by clj=
(do (swap! bin->val assoc bin val)
true))))))
#_{:bin->val @bin->val
:val->bin @val->bin}
nil)))
(comment
(tc-gens/sample tc-gens 10)
(:result (qc-prop-bijection 80))
(let [{:keys [result bin->val val->bin]} (qc-prop-bijection 10)]
[result (vals bin->val)]))
(deftest _gc-prop-bijection
(is (:result (qc-prop-bijection tc-num-tests))))
;;;; Thread safety
(deftest _thread-safe
(is
(let [futures
(mapv
(fn [_]
(future
2020-07-24 15:08:38 +00:00
(= (thaw (freeze test-data)) test-data)))
(range 50))]
(every? deref futures)))
(is
(let [futures
(mapv
(fn [_]
(future
2020-07-24 15:08:38 +00:00
(= (thaw (freeze test-data {:password [:salted "password"]})
{:password [:salted "password"]})
test-data)))
(range 50))]
(every? deref futures)))
(is
(let [futures
(mapv
(fn [_]
(future
2020-07-24 15:08:38 +00:00
(= (thaw (freeze test-data {:password [:cached "password"]})
{:password [:cached "password"]})
test-data)))
(range 50))]
(every? deref futures))))
;;;; Redefs
(defrecord MyFoo [] Object (toString [_] "v1"))
(str (thaw (freeze (MyFoo.))))
(defrecord MyFoo [] Object (toString [_] "v2"))
(deftest _redefs
(is (= (str (thaw (freeze (MyFoo.)))) "v2")))
[BREAKING] [Security] Fix RCE vulnerability Fix a Remote Code Execution (RCE) vulnerability identified in an excellent report by Timo Mihaljov (@solita-timo-mihaljov). You are vulnerable iff both: 1. You are using Nippy to serialize and deserialize data from an UNTRUSTED SOURCE. 2. You have a vulnerable ("gadget") class on your classpath. Notably Clojure <= 1.8 includes such a class [1]. Many other libraries do too, some examples at [2]. To prevent this risk, a Serialization whitelist has been added. Any classes not *explicitly* authorized by the whitelist to use Serialization will NOT be permitted to. The default whitelist is EMPTY, meaning this is a BREAKING change iff you make use of Nippy's Serialization support. In this case, you'll need to update the whitelist for your needs. For more info see the `*serializable-whitelist*` docstring. [1] https://clojure.atlassian.net/browse/CLJ-2204 [2] https://github.com/frohoff/ysoserial Further info below provided by Timo: ------------------------------------ Deserialization vulnerabilities are exploited by constructing objects of classes whose constructors perform some action that's useful to the attacker. A class like this is called a gadget, and a collection of such classes that can be combined to reach the attacker's goal is called a gadget chain. There are three prerequisites for exploiting a deserialization vulnerability: 1) The attacker must be able to control the deserialized data, for example, by gaining write access to the data store where trusted parties serialize data or by exploiting some other vulnerability on the other end of a communications channel. 2) The deserializer must construct objects of classes specified in the serialized data. In other words, the attacker must have full control over which classes get instantiated. 3) The classpath must contain gadgets that can be combined into a gadget chain. The vulnerable code is in Nippy's function `read-serializable`, which calls the `readObject` method of `ObjectInputStream`. I have only tested the PoC with the latest stable version, 2.14.0, but looking at Nippy's Git history, I believe all versions starting with the following commit are vulnerable: commit 9448d2b3cec5c28a1c7594dec00c01d66bb61a8b [Thu Oct 24 13:47:25 2013 +0700] For a user to be affected, they must: 1) use Nippy to serialize untrusted input, and 2) have a gadget chain on their classpath. I suspect (but haven't verified) that using Nippy's encryption feature prevents exploitation in some cases, but if it's used to encrypt the communications between two systems, one compromised endpoint could send encrypted but attacker-controlled data to the other. Ysoserial [4] contains a list of some Java libraries with known gadget chains. If any of those libraries can be found on the user's classpath, they are known to be vulnerable. (Ysoserial's list is not exhaustive, so even if a user doesn't have these particular libraries on their classpath, they may still have some other gadget chains loaded.) Unfortunately Clojure versions before 1.9 contained a gadget chain in the standard library [5][6], so all Nippy users running Clojure 1.8 or earlier are vulnerable. (Note that users of later Clojure versions may or may not be vulnerable, depending on whether they have gadget chains from other libraries on their classpath.) [4] https://github.com/frohoff/ysoserial [5] https://groups.google.com/forum/#!msg/clojure/WaL3hHzsevI/7zHU-L7LBQAJ [6] https://clojure.atlassian.net/browse/CLJ-2204
2020-07-23 10:33:05 +00:00
;;;; Serializable
(do
(def ^:private semcn "java.util.concurrent.Semaphore")
(def ^:private sem (java.util.concurrent.Semaphore. 1))
(defn- sem? [x] (instance? java.util.concurrent.Semaphore x)))
[BREAKING] [Security] Fix RCE vulnerability Fix a Remote Code Execution (RCE) vulnerability identified in an excellent report by Timo Mihaljov (@solita-timo-mihaljov). You are vulnerable iff both: 1. You are using Nippy to serialize and deserialize data from an UNTRUSTED SOURCE. 2. You have a vulnerable ("gadget") class on your classpath. Notably Clojure <= 1.8 includes such a class [1]. Many other libraries do too, some examples at [2]. To prevent this risk, a Serialization whitelist has been added. Any classes not *explicitly* authorized by the whitelist to use Serialization will NOT be permitted to. The default whitelist is EMPTY, meaning this is a BREAKING change iff you make use of Nippy's Serialization support. In this case, you'll need to update the whitelist for your needs. For more info see the `*serializable-whitelist*` docstring. [1] https://clojure.atlassian.net/browse/CLJ-2204 [2] https://github.com/frohoff/ysoserial Further info below provided by Timo: ------------------------------------ Deserialization vulnerabilities are exploited by constructing objects of classes whose constructors perform some action that's useful to the attacker. A class like this is called a gadget, and a collection of such classes that can be combined to reach the attacker's goal is called a gadget chain. There are three prerequisites for exploiting a deserialization vulnerability: 1) The attacker must be able to control the deserialized data, for example, by gaining write access to the data store where trusted parties serialize data or by exploiting some other vulnerability on the other end of a communications channel. 2) The deserializer must construct objects of classes specified in the serialized data. In other words, the attacker must have full control over which classes get instantiated. 3) The classpath must contain gadgets that can be combined into a gadget chain. The vulnerable code is in Nippy's function `read-serializable`, which calls the `readObject` method of `ObjectInputStream`. I have only tested the PoC with the latest stable version, 2.14.0, but looking at Nippy's Git history, I believe all versions starting with the following commit are vulnerable: commit 9448d2b3cec5c28a1c7594dec00c01d66bb61a8b [Thu Oct 24 13:47:25 2013 +0700] For a user to be affected, they must: 1) use Nippy to serialize untrusted input, and 2) have a gadget chain on their classpath. I suspect (but haven't verified) that using Nippy's encryption feature prevents exploitation in some cases, but if it's used to encrypt the communications between two systems, one compromised endpoint could send encrypted but attacker-controlled data to the other. Ysoserial [4] contains a list of some Java libraries with known gadget chains. If any of those libraries can be found on the user's classpath, they are known to be vulnerable. (Ysoserial's list is not exhaustive, so even if a user doesn't have these particular libraries on their classpath, they may still have some other gadget chains loaded.) Unfortunately Clojure versions before 1.9 contained a gadget chain in the standard library [5][6], so all Nippy users running Clojure 1.8 or earlier are vulnerable. (Note that users of later Clojure versions may or may not be vulnerable, depending on whether they have gadget chains from other libraries on their classpath.) [4] https://github.com/frohoff/ysoserial [5] https://groups.google.com/forum/#!msg/clojure/WaL3hHzsevI/7zHU-L7LBQAJ [6] https://clojure.atlassian.net/browse/CLJ-2204
2020-07-23 10:33:05 +00:00
2020-09-10 12:30:43 +00:00
(deftest _serializable
(is (= nippy/*thaw-serializable-allowlist* #{"base.1" "base.2" "add.1" "add.2"})
"JVM properties override initial allowlist values")
[BREAKING] [Security] Fix RCE vulnerability Fix a Remote Code Execution (RCE) vulnerability identified in an excellent report by Timo Mihaljov (@solita-timo-mihaljov). You are vulnerable iff both: 1. You are using Nippy to serialize and deserialize data from an UNTRUSTED SOURCE. 2. You have a vulnerable ("gadget") class on your classpath. Notably Clojure <= 1.8 includes such a class [1]. Many other libraries do too, some examples at [2]. To prevent this risk, a Serialization whitelist has been added. Any classes not *explicitly* authorized by the whitelist to use Serialization will NOT be permitted to. The default whitelist is EMPTY, meaning this is a BREAKING change iff you make use of Nippy's Serialization support. In this case, you'll need to update the whitelist for your needs. For more info see the `*serializable-whitelist*` docstring. [1] https://clojure.atlassian.net/browse/CLJ-2204 [2] https://github.com/frohoff/ysoserial Further info below provided by Timo: ------------------------------------ Deserialization vulnerabilities are exploited by constructing objects of classes whose constructors perform some action that's useful to the attacker. A class like this is called a gadget, and a collection of such classes that can be combined to reach the attacker's goal is called a gadget chain. There are three prerequisites for exploiting a deserialization vulnerability: 1) The attacker must be able to control the deserialized data, for example, by gaining write access to the data store where trusted parties serialize data or by exploiting some other vulnerability on the other end of a communications channel. 2) The deserializer must construct objects of classes specified in the serialized data. In other words, the attacker must have full control over which classes get instantiated. 3) The classpath must contain gadgets that can be combined into a gadget chain. The vulnerable code is in Nippy's function `read-serializable`, which calls the `readObject` method of `ObjectInputStream`. I have only tested the PoC with the latest stable version, 2.14.0, but looking at Nippy's Git history, I believe all versions starting with the following commit are vulnerable: commit 9448d2b3cec5c28a1c7594dec00c01d66bb61a8b [Thu Oct 24 13:47:25 2013 +0700] For a user to be affected, they must: 1) use Nippy to serialize untrusted input, and 2) have a gadget chain on their classpath. I suspect (but haven't verified) that using Nippy's encryption feature prevents exploitation in some cases, but if it's used to encrypt the communications between two systems, one compromised endpoint could send encrypted but attacker-controlled data to the other. Ysoserial [4] contains a list of some Java libraries with known gadget chains. If any of those libraries can be found on the user's classpath, they are known to be vulnerable. (Ysoserial's list is not exhaustive, so even if a user doesn't have these particular libraries on their classpath, they may still have some other gadget chains loaded.) Unfortunately Clojure versions before 1.9 contained a gadget chain in the standard library [5][6], so all Nippy users running Clojure 1.8 or earlier are vulnerable. (Note that users of later Clojure versions may or may not be vulnerable, depending on whether they have gadget chains from other libraries on their classpath.) [4] https://github.com/frohoff/ysoserial [5] https://groups.google.com/forum/#!msg/clojure/WaL3hHzsevI/7zHU-L7LBQAJ [6] https://clojure.atlassian.net/browse/CLJ-2204
2020-07-23 10:33:05 +00:00
(is (thrown? Exception (nippy/freeze sem {:serializable-allowlist #{}}))
"Can't freeze Serializable objects unless approved by allowlist")
[BREAKING] [Security] Fix RCE vulnerability Fix a Remote Code Execution (RCE) vulnerability identified in an excellent report by Timo Mihaljov (@solita-timo-mihaljov). You are vulnerable iff both: 1. You are using Nippy to serialize and deserialize data from an UNTRUSTED SOURCE. 2. You have a vulnerable ("gadget") class on your classpath. Notably Clojure <= 1.8 includes such a class [1]. Many other libraries do too, some examples at [2]. To prevent this risk, a Serialization whitelist has been added. Any classes not *explicitly* authorized by the whitelist to use Serialization will NOT be permitted to. The default whitelist is EMPTY, meaning this is a BREAKING change iff you make use of Nippy's Serialization support. In this case, you'll need to update the whitelist for your needs. For more info see the `*serializable-whitelist*` docstring. [1] https://clojure.atlassian.net/browse/CLJ-2204 [2] https://github.com/frohoff/ysoserial Further info below provided by Timo: ------------------------------------ Deserialization vulnerabilities are exploited by constructing objects of classes whose constructors perform some action that's useful to the attacker. A class like this is called a gadget, and a collection of such classes that can be combined to reach the attacker's goal is called a gadget chain. There are three prerequisites for exploiting a deserialization vulnerability: 1) The attacker must be able to control the deserialized data, for example, by gaining write access to the data store where trusted parties serialize data or by exploiting some other vulnerability on the other end of a communications channel. 2) The deserializer must construct objects of classes specified in the serialized data. In other words, the attacker must have full control over which classes get instantiated. 3) The classpath must contain gadgets that can be combined into a gadget chain. The vulnerable code is in Nippy's function `read-serializable`, which calls the `readObject` method of `ObjectInputStream`. I have only tested the PoC with the latest stable version, 2.14.0, but looking at Nippy's Git history, I believe all versions starting with the following commit are vulnerable: commit 9448d2b3cec5c28a1c7594dec00c01d66bb61a8b [Thu Oct 24 13:47:25 2013 +0700] For a user to be affected, they must: 1) use Nippy to serialize untrusted input, and 2) have a gadget chain on their classpath. I suspect (but haven't verified) that using Nippy's encryption feature prevents exploitation in some cases, but if it's used to encrypt the communications between two systems, one compromised endpoint could send encrypted but attacker-controlled data to the other. Ysoserial [4] contains a list of some Java libraries with known gadget chains. If any of those libraries can be found on the user's classpath, they are known to be vulnerable. (Ysoserial's list is not exhaustive, so even if a user doesn't have these particular libraries on their classpath, they may still have some other gadget chains loaded.) Unfortunately Clojure versions before 1.9 contained a gadget chain in the standard library [5][6], so all Nippy users running Clojure 1.8 or earlier are vulnerable. (Note that users of later Clojure versions may or may not be vulnerable, depending on whether they have gadget chains from other libraries on their classpath.) [4] https://github.com/frohoff/ysoserial [5] https://groups.google.com/forum/#!msg/clojure/WaL3hHzsevI/7zHU-L7LBQAJ [6] https://clojure.atlassian.net/browse/CLJ-2204
2020-07-23 10:33:05 +00:00
2020-09-10 12:30:43 +00:00
(is (sem?
(nippy/thaw
(nippy/freeze sem {:serializable-allowlist #{semcn}})
{:serializable-allowlist #{semcn}}))
[BREAKING] [Security] Fix RCE vulnerability Fix a Remote Code Execution (RCE) vulnerability identified in an excellent report by Timo Mihaljov (@solita-timo-mihaljov). You are vulnerable iff both: 1. You are using Nippy to serialize and deserialize data from an UNTRUSTED SOURCE. 2. You have a vulnerable ("gadget") class on your classpath. Notably Clojure <= 1.8 includes such a class [1]. Many other libraries do too, some examples at [2]. To prevent this risk, a Serialization whitelist has been added. Any classes not *explicitly* authorized by the whitelist to use Serialization will NOT be permitted to. The default whitelist is EMPTY, meaning this is a BREAKING change iff you make use of Nippy's Serialization support. In this case, you'll need to update the whitelist for your needs. For more info see the `*serializable-whitelist*` docstring. [1] https://clojure.atlassian.net/browse/CLJ-2204 [2] https://github.com/frohoff/ysoserial Further info below provided by Timo: ------------------------------------ Deserialization vulnerabilities are exploited by constructing objects of classes whose constructors perform some action that's useful to the attacker. A class like this is called a gadget, and a collection of such classes that can be combined to reach the attacker's goal is called a gadget chain. There are three prerequisites for exploiting a deserialization vulnerability: 1) The attacker must be able to control the deserialized data, for example, by gaining write access to the data store where trusted parties serialize data or by exploiting some other vulnerability on the other end of a communications channel. 2) The deserializer must construct objects of classes specified in the serialized data. In other words, the attacker must have full control over which classes get instantiated. 3) The classpath must contain gadgets that can be combined into a gadget chain. The vulnerable code is in Nippy's function `read-serializable`, which calls the `readObject` method of `ObjectInputStream`. I have only tested the PoC with the latest stable version, 2.14.0, but looking at Nippy's Git history, I believe all versions starting with the following commit are vulnerable: commit 9448d2b3cec5c28a1c7594dec00c01d66bb61a8b [Thu Oct 24 13:47:25 2013 +0700] For a user to be affected, they must: 1) use Nippy to serialize untrusted input, and 2) have a gadget chain on their classpath. I suspect (but haven't verified) that using Nippy's encryption feature prevents exploitation in some cases, but if it's used to encrypt the communications between two systems, one compromised endpoint could send encrypted but attacker-controlled data to the other. Ysoserial [4] contains a list of some Java libraries with known gadget chains. If any of those libraries can be found on the user's classpath, they are known to be vulnerable. (Ysoserial's list is not exhaustive, so even if a user doesn't have these particular libraries on their classpath, they may still have some other gadget chains loaded.) Unfortunately Clojure versions before 1.9 contained a gadget chain in the standard library [5][6], so all Nippy users running Clojure 1.8 or earlier are vulnerable. (Note that users of later Clojure versions may or may not be vulnerable, depending on whether they have gadget chains from other libraries on their classpath.) [4] https://github.com/frohoff/ysoserial [5] https://groups.google.com/forum/#!msg/clojure/WaL3hHzsevI/7zHU-L7LBQAJ [6] https://clojure.atlassian.net/browse/CLJ-2204
2020-07-23 10:33:05 +00:00
"Can freeze and thaw Serializable objects if approved by allowlist")
[BREAKING] [Security] Fix RCE vulnerability Fix a Remote Code Execution (RCE) vulnerability identified in an excellent report by Timo Mihaljov (@solita-timo-mihaljov). You are vulnerable iff both: 1. You are using Nippy to serialize and deserialize data from an UNTRUSTED SOURCE. 2. You have a vulnerable ("gadget") class on your classpath. Notably Clojure <= 1.8 includes such a class [1]. Many other libraries do too, some examples at [2]. To prevent this risk, a Serialization whitelist has been added. Any classes not *explicitly* authorized by the whitelist to use Serialization will NOT be permitted to. The default whitelist is EMPTY, meaning this is a BREAKING change iff you make use of Nippy's Serialization support. In this case, you'll need to update the whitelist for your needs. For more info see the `*serializable-whitelist*` docstring. [1] https://clojure.atlassian.net/browse/CLJ-2204 [2] https://github.com/frohoff/ysoserial Further info below provided by Timo: ------------------------------------ Deserialization vulnerabilities are exploited by constructing objects of classes whose constructors perform some action that's useful to the attacker. A class like this is called a gadget, and a collection of such classes that can be combined to reach the attacker's goal is called a gadget chain. There are three prerequisites for exploiting a deserialization vulnerability: 1) The attacker must be able to control the deserialized data, for example, by gaining write access to the data store where trusted parties serialize data or by exploiting some other vulnerability on the other end of a communications channel. 2) The deserializer must construct objects of classes specified in the serialized data. In other words, the attacker must have full control over which classes get instantiated. 3) The classpath must contain gadgets that can be combined into a gadget chain. The vulnerable code is in Nippy's function `read-serializable`, which calls the `readObject` method of `ObjectInputStream`. I have only tested the PoC with the latest stable version, 2.14.0, but looking at Nippy's Git history, I believe all versions starting with the following commit are vulnerable: commit 9448d2b3cec5c28a1c7594dec00c01d66bb61a8b [Thu Oct 24 13:47:25 2013 +0700] For a user to be affected, they must: 1) use Nippy to serialize untrusted input, and 2) have a gadget chain on their classpath. I suspect (but haven't verified) that using Nippy's encryption feature prevents exploitation in some cases, but if it's used to encrypt the communications between two systems, one compromised endpoint could send encrypted but attacker-controlled data to the other. Ysoserial [4] contains a list of some Java libraries with known gadget chains. If any of those libraries can be found on the user's classpath, they are known to be vulnerable. (Ysoserial's list is not exhaustive, so even if a user doesn't have these particular libraries on their classpath, they may still have some other gadget chains loaded.) Unfortunately Clojure versions before 1.9 contained a gadget chain in the standard library [5][6], so all Nippy users running Clojure 1.8 or earlier are vulnerable. (Note that users of later Clojure versions may or may not be vulnerable, depending on whether they have gadget chains from other libraries on their classpath.) [4] https://github.com/frohoff/ysoserial [5] https://groups.google.com/forum/#!msg/clojure/WaL3hHzsevI/7zHU-L7LBQAJ [6] https://clojure.atlassian.net/browse/CLJ-2204
2020-07-23 10:33:05 +00:00
2020-09-10 12:30:43 +00:00
(is (sem?
(nippy/thaw
(nippy/freeze sem {:serializable-allowlist #{"java.util.concurrent.*"}})
{:serializable-allowlist #{"java.util.concurrent.*"}}))
[BREAKING] [Security] Fix RCE vulnerability Fix a Remote Code Execution (RCE) vulnerability identified in an excellent report by Timo Mihaljov (@solita-timo-mihaljov). You are vulnerable iff both: 1. You are using Nippy to serialize and deserialize data from an UNTRUSTED SOURCE. 2. You have a vulnerable ("gadget") class on your classpath. Notably Clojure <= 1.8 includes such a class [1]. Many other libraries do too, some examples at [2]. To prevent this risk, a Serialization whitelist has been added. Any classes not *explicitly* authorized by the whitelist to use Serialization will NOT be permitted to. The default whitelist is EMPTY, meaning this is a BREAKING change iff you make use of Nippy's Serialization support. In this case, you'll need to update the whitelist for your needs. For more info see the `*serializable-whitelist*` docstring. [1] https://clojure.atlassian.net/browse/CLJ-2204 [2] https://github.com/frohoff/ysoserial Further info below provided by Timo: ------------------------------------ Deserialization vulnerabilities are exploited by constructing objects of classes whose constructors perform some action that's useful to the attacker. A class like this is called a gadget, and a collection of such classes that can be combined to reach the attacker's goal is called a gadget chain. There are three prerequisites for exploiting a deserialization vulnerability: 1) The attacker must be able to control the deserialized data, for example, by gaining write access to the data store where trusted parties serialize data or by exploiting some other vulnerability on the other end of a communications channel. 2) The deserializer must construct objects of classes specified in the serialized data. In other words, the attacker must have full control over which classes get instantiated. 3) The classpath must contain gadgets that can be combined into a gadget chain. The vulnerable code is in Nippy's function `read-serializable`, which calls the `readObject` method of `ObjectInputStream`. I have only tested the PoC with the latest stable version, 2.14.0, but looking at Nippy's Git history, I believe all versions starting with the following commit are vulnerable: commit 9448d2b3cec5c28a1c7594dec00c01d66bb61a8b [Thu Oct 24 13:47:25 2013 +0700] For a user to be affected, they must: 1) use Nippy to serialize untrusted input, and 2) have a gadget chain on their classpath. I suspect (but haven't verified) that using Nippy's encryption feature prevents exploitation in some cases, but if it's used to encrypt the communications between two systems, one compromised endpoint could send encrypted but attacker-controlled data to the other. Ysoserial [4] contains a list of some Java libraries with known gadget chains. If any of those libraries can be found on the user's classpath, they are known to be vulnerable. (Ysoserial's list is not exhaustive, so even if a user doesn't have these particular libraries on their classpath, they may still have some other gadget chains loaded.) Unfortunately Clojure versions before 1.9 contained a gadget chain in the standard library [5][6], so all Nippy users running Clojure 1.8 or earlier are vulnerable. (Note that users of later Clojure versions may or may not be vulnerable, depending on whether they have gadget chains from other libraries on their classpath.) [4] https://github.com/frohoff/ysoserial [5] https://groups.google.com/forum/#!msg/clojure/WaL3hHzsevI/7zHU-L7LBQAJ [6] https://clojure.atlassian.net/browse/CLJ-2204
2020-07-23 10:33:05 +00:00
"Strings in allowlist sets may contain \"*\" wildcards")
(let [ba (nippy/freeze sem #_{:serializable-allowlist "*"})
thawed (nippy/thaw ba {:serializable-allowlist #{}})]
2020-09-10 12:30:43 +00:00
(is (= :quarantined (get-in thawed [:nippy/unthawable :cause]))
"Serializable objects will be quarantined when approved for freezing but not thawing.")
2020-09-10 12:30:43 +00:00
(is (sem? (nippy/read-quarantined-serializable-object-unsafe! thawed))
"Quarantined Serializable objects can still be manually force-read.")
[BREAKING] [Security] Fix RCE vulnerability Fix a Remote Code Execution (RCE) vulnerability identified in an excellent report by Timo Mihaljov (@solita-timo-mihaljov). You are vulnerable iff both: 1. You are using Nippy to serialize and deserialize data from an UNTRUSTED SOURCE. 2. You have a vulnerable ("gadget") class on your classpath. Notably Clojure <= 1.8 includes such a class [1]. Many other libraries do too, some examples at [2]. To prevent this risk, a Serialization whitelist has been added. Any classes not *explicitly* authorized by the whitelist to use Serialization will NOT be permitted to. The default whitelist is EMPTY, meaning this is a BREAKING change iff you make use of Nippy's Serialization support. In this case, you'll need to update the whitelist for your needs. For more info see the `*serializable-whitelist*` docstring. [1] https://clojure.atlassian.net/browse/CLJ-2204 [2] https://github.com/frohoff/ysoserial Further info below provided by Timo: ------------------------------------ Deserialization vulnerabilities are exploited by constructing objects of classes whose constructors perform some action that's useful to the attacker. A class like this is called a gadget, and a collection of such classes that can be combined to reach the attacker's goal is called a gadget chain. There are three prerequisites for exploiting a deserialization vulnerability: 1) The attacker must be able to control the deserialized data, for example, by gaining write access to the data store where trusted parties serialize data or by exploiting some other vulnerability on the other end of a communications channel. 2) The deserializer must construct objects of classes specified in the serialized data. In other words, the attacker must have full control over which classes get instantiated. 3) The classpath must contain gadgets that can be combined into a gadget chain. The vulnerable code is in Nippy's function `read-serializable`, which calls the `readObject` method of `ObjectInputStream`. I have only tested the PoC with the latest stable version, 2.14.0, but looking at Nippy's Git history, I believe all versions starting with the following commit are vulnerable: commit 9448d2b3cec5c28a1c7594dec00c01d66bb61a8b [Thu Oct 24 13:47:25 2013 +0700] For a user to be affected, they must: 1) use Nippy to serialize untrusted input, and 2) have a gadget chain on their classpath. I suspect (but haven't verified) that using Nippy's encryption feature prevents exploitation in some cases, but if it's used to encrypt the communications between two systems, one compromised endpoint could send encrypted but attacker-controlled data to the other. Ysoserial [4] contains a list of some Java libraries with known gadget chains. If any of those libraries can be found on the user's classpath, they are known to be vulnerable. (Ysoserial's list is not exhaustive, so even if a user doesn't have these particular libraries on their classpath, they may still have some other gadget chains loaded.) Unfortunately Clojure versions before 1.9 contained a gadget chain in the standard library [5][6], so all Nippy users running Clojure 1.8 or earlier are vulnerable. (Note that users of later Clojure versions may or may not be vulnerable, depending on whether they have gadget chains from other libraries on their classpath.) [4] https://github.com/frohoff/ysoserial [5] https://groups.google.com/forum/#!msg/clojure/WaL3hHzsevI/7zHU-L7LBQAJ [6] https://clojure.atlassian.net/browse/CLJ-2204
2020-07-23 10:33:05 +00:00
2020-09-10 12:30:43 +00:00
(is (sem? (nippy/read-quarantined-serializable-object-unsafe!
(nippy/thaw (nippy/freeze thawed))))
"Quarantined Serializable objects are themselves safely transportable."))
(let [obj
(nippy/thaw
(nippy/freeze sem)
{:serializable-allowlist "allow-and-record"})]
(is (sem? obj)
"Special \"allow-and-record\" allowlist permits any class")
(is
(contains? (nippy/get-recorded-serializable-classes) semcn)
"Special \"allow-and-record\" allowlist records classes")))
;;;; Metadata
(deftest _metadata
(is
(:has-meta?
(meta
(nippy/thaw
(nippy/freeze (with-meta [] {:has-meta? true}) {:incl-metadata? true})
{:incl-metadata? true}
)))
"Metadata successfully included")
(is
(nil?
(meta
(nippy/thaw
(nippy/freeze (with-meta [] {:has-meta? true}) {:incl-metadata? true})
{:incl-metadata? false}
)))
"Metadata successfully excluded by thaw")
(is
(nil?
(meta
(nippy/thaw
(nippy/freeze (with-meta [] {:has-meta? true}) {:incl-metadata? false})
{:incl-metadata? true}
)))
"Metadata successfully excluded by freeze"))
;;;; Benchmarks
(deftest _benchmarks
(is (benchmarks/bench {})) ; Also tests :cached passwords
)