summaryrefslogtreecommitdiff
path: root/changes
AgeCommit message (Collapse)Author
2017-06-08Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-06-08TROVE-2017-005: Fix assertion failure in connection_edge_process_relay_cellDavid Goulet
On an hidden service rendezvous circuit, a BEGIN_DIR could be sent (maliciously) which would trigger a tor_assert() because connection_edge_process_relay_cell() thought that the circuit is an or_circuit_t but is an origin circuit in reality. Fixes #22494 Reported-by: Roger Dingledine <arma@torproject.org> Signed-off-by: David Goulet <dgoulet@torproject.org>
2017-06-05Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-06-05Fix undefined behavior in geoip_parse_entry().Nick Mathewson
Fixes bug 22490; bugfix on 6a241ff3ffe7dc1 in 0.2.4.6-alpha. Found by teor using clang-5.0's AddressSanitizer stack-use-after-scope.
2017-05-08Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-05-08Update geoip and geoip6 to the May 2 2017 database.Karsten Loesing
2017-04-06Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-04-06Update geoip and geoip6 to the April 4 2017 database.Karsten Loesing
2017-03-08Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-03-08Update geoip and geoip6 to the March 7 2017 database.Karsten Loesing
2017-02-15Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-02-14Avoid integer underflow in tor_version_compare.Nick Mathewson
Fix for TROVE-2017-001 and bug 21278. (Note: Instead of handling signed ints "correctly", we keep the old behavior, except for the part where we would crash with -ftrapv.)
2017-02-13be sure to remember the changes file for #20384Roger Dingledine
2017-02-13Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-02-12Update geoip and geoip6 to the February 8 2017 database.Karsten Loesing
2017-02-07Merge remote-tracking branch 'public/bug18710_025' into maint-0.2.5Nick Mathewson
2017-02-07Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-02-07Change behavior on missing/present event to warn instead of asserting.Nick Mathewson
Add a changes file.
2017-02-07Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-02-07Backport the tonga->bifroest move to 0.2.4.Nick Mathewson
This is a backport of 19728 and 19690
2017-02-07Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-02-07Merge remote-tracking branch 'public/bug19152_024_v2' into maint-0.2.4Nick Mathewson
2017-02-07Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-02-07Merge remote-tracking branch 'public/bug17404_024' into maint-0.2.4Nick Mathewson
2017-02-07Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-02-07Make memwipe() do nothing when passed a NULL pointer or zero sizeteor (Tim Wilson-Brown)
Check size argument to memwipe() for underflow. Closes bug #18089. Reported by "gk", patch by "teor". Bugfix on 0.2.3.25 and 0.2.4.6-alpha (#7352), commit 49dd5ef3 on 7 Nov 2012.
2017-02-07Fix out-of-bounds read in INTRODUCE2 client authJohn Brooks
The length of auth_data from an INTRODUCE2 cell is checked when the auth_type is recognized (1 or 2), but not for any other non-zero auth_type. Later, auth_data is assumed to have at least REND_DESC_COOKIE_LEN bytes, leading to a client-triggered out of bounds read. Fixed by checking auth_len before comparing the descriptor cookie against known clients. Fixes #15823; bugfix on 0.2.1.6-alpha.
2017-01-11Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2017-01-04Update geoip and geoip6 to the January 4 2017 database.Karsten Loesing
2016-12-20Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-12-18Fix parsing bug with unecognized token at EOSNick Mathewson
In get_token(), we could read one byte past the end of the region. This is only a big problem in the case where the region itself is (a) potentially hostile, and (b) not explicitly nul-terminated. This patch fixes the underlying bug, and also makes sure that the one remaining case of not-NUL-terminated potentially hostile data gets NUL-terminated. Fix for bug 21018, TROVE-2016-12-002, and CVE-2016-1254
2016-12-09Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-12-09Update geoip and geoip6 to the December 7 2016 database.Karsten Loesing
2016-11-07Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-11-07Update geoip and geoip6 to the November 3 2016 database.Karsten Loesing
2016-10-06Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-10-05Update geoip and geoip6 to the October 6 2016 database.Karsten Loesing
2016-09-07Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-09-07Update geoip and geoip6 to the September 6 2016 database.Karsten Loesing
2016-08-12Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-08-12Update geoip and geoip6 to the August 2 2016 database.Karsten Loesing
2016-07-19Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-07-18Update geoip and geoip6 to the July 6 2016 database.Karsten Loesing
2016-07-05Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-07-05whoops. changelog file for 19271.Nick Mathewson
2016-06-13Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-06-12Update geoip and geoip6 to the June 7 2016 database.Karsten Loesing
2016-05-25Fix a dangling pointer issue in our RSA keygen codeNick Mathewson
If OpenSSL fails to generate an RSA key, do not retain a dangling pointer to the previous (uninitialized) key value. The impact here should be limited to a difficult-to-trigger crash, if OpenSSL is running an engine that makes key generation failures possible, or if OpenSSL runs out of memory. Fixes bug 19152; bugfix on 0.2.1.10-alpha. Found by Yuan Jochen Kang, Suman Jana, and Baishakhi Ray. This is potentially scary stuff, so let me walk through my analysis. I think this is a bug, and a backport candidate, but not remotely triggerable in any useful way. Observation 1a: Looking over the OpenSSL code here, the only way we can really fail in the non-engine case is if malloc() fails. But if malloc() is failing, then tor_malloc() calls should be tor_asserting -- the only way that an attacker could do an exploit here would be to figure out some way to make malloc() fail when openssl does it, but work whenever Tor does it. (Also ordinary malloc() doesn't fail on platforms like Linux that overcommit.) Observation 1b: Although engines are _allowed_ to fail in extra ways, I can't find much evidence online that they actually _do_ fail in practice. More evidence would be nice, though. Observation 2: We don't call crypto_pk_generate*() all that often, and we don't do it in response to external inputs. The only way to get it to happen remotely would be by causing a hidden service to build new introduction points. Observation 3a: So, let's assume that both of the above observations are wrong, and the attacker can make us generate a crypto_pk_env_t with a dangling pointer in its 'key' field, and not immediately crash. This dangling pointer will point to what used to be an RSA structure, with the fields all set to NULL. Actually using this RSA structure, before the memory is reused for anything else, will cause a crash. In nearly every function where we call crypto_pk_generate*(), we quickly use the RSA key pointer -- either to sign something, or to encode the key, or to free the key. The only exception is when we generate an intro key in rend_consider_services_intro_points(). In that case, we don't actually use the key until the intro circuit is opened -- at which point we encode it, and use it to sign an introduction request. So in order to exploit this bug to do anything besides crash Tor, the attacker needs to make sure that by the time the introduction circuit completes, either: * the e, d, and n BNs look valid, and at least one of the other BNs is still NULL. OR * all 8 of the BNs must look valid. To look like a valid BN, *they* all need to have their 'top' index plus their 'd' pointer indicate an addressable region in memory. So actually getting useful data of of this, rather than a crash, is going to be pretty damn hard. You'd have to force an introduction point to be created (or wait for one to be created), and force that particular crypto_pk_generate*() to fail, and then arrange for the memory that the RSA points to to in turn point to 3...8 valid BNs, all by the time the introduction circuit completes. Naturally, the signature won't check as valid [*], so the intro point will reject the ESTABLISH_INTRO cell. So you need to _be_ the introduction point, or you don't actually see this information. [*] Okay, so if you could somehow make the 'rsa' pointer point to a different valid RSA key, then you'd get a valid signature of an ESTABLISH_INTRO cell using a key that was supposed to be used for something else ... but nothing else looks like that, so you can't use that signature elsewhere. Observation 3b: Your best bet as an attacker would be to make the dangling RSA pointer actually contain a fake method, with a fake RSA_private_encrypt function that actually pointed to code you wanted to execute. You'd still need to transit 3 or 4 pointers deep though in order to make that work. Conclusion: By 1, you probably can't trigger this without Tor crashing from OOM. By 2, you probably can't trigger this reliably. By 3, even if I'm wrong about 1 and 2, you have to jump through a pretty big array of hoops in order to get any kind of data leak or code execution. So I'm calling it a bug, but not a security hole. Still worth patching.
2016-05-09Merge branch 'maint-0.2.4' into maint-0.2.5Nick Mathewson
2016-05-09Update geoip and geoip6 to the May 4 2016 database.Karsten Loesing