Git-Mirrors/monero
1
0
Fork 0
mirror of https://github.com/monero-project/monero.git synced 2024-12-25 22:49:24 -05:00
Code Issues Packages Projects Releases Wiki Activity

Fix --anonymous-inbound data leak

Browse Source
This commit is contained in:
Lee *!* Clagett 2024-12-19 15:26:29 -05:00
parent 893916ad09
commit dc7e3ed753
1 changed files with 23 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
src/p2p/net_node.inl
View File

@ -2470,6 +2470,7 @@ namespace nodetool
//fill response //fill response
const epee::net_utils::zone zone_type = context.m_remote_address.get_zone(); const epee::net_utils::zone zone_type = context.m_remote_address.get_zone();
const bool is_public = (zone_type == epee::net_utils::zone::public_);
network_zone& zone = m_network_zones.at(zone_type); network_zone& zone = m_network_zones.at(zone_type);
//will add self to peerlist if in same zone as outgoing later in this function //will add self to peerlist if in same zone as outgoing later in this function
@ -2479,6 +2480,21 @@ namespace nodetool
std::vector<peerlist_entry> local_peerlist_new; std::vector<peerlist_entry> local_peerlist_new;
zone.m_peerlist.get_peerlist_head(local_peerlist_new, true, max_peerlist_size); zone.m_peerlist.get_peerlist_head(local_peerlist_new, true, max_peerlist_size);
/* Tor/I2P nodes receiving connections via forwarding (from tor/i2p daemon)
do not know the address of the connecting peer. This is relayed to them,
iff the node has setup an inbound hidden service. The other peer will have
to use the random peer_id value to link the two. My initial thought is that
the inbound peer should leave the other side marked as `<unknown tor host>`,
etc., because someone could give faulty addresses over Tor/I2P to get the
real peer with that identity banned/blacklisted.
\note Insert into `local_peerlist_new` so that it is only sent once like
the other peers. */
if(outgoing_to_same_zone)
local_peerlist_new.push_back(
peerlist_entry{zone.m_our_address, zone.m_config.m_peer_id, (is_public ? std::time(nullptr) : 0)}
);
//only include out peers we did not already send //only include out peers we did not already send
rsp.local_peerlist_new.reserve(local_peerlist_new.size()); rsp.local_peerlist_new.reserve(local_peerlist_new.size());
for (auto &pe: local_peerlist_new) for (auto &pe: local_peerlist_new)
@ -2486,19 +2502,16 @@ namespace nodetool
if (!context.sent_addresses.insert(pe.adr).second) if (!context.sent_addresses.insert(pe.adr).second)
continue; continue;
rsp.local_peerlist_new.push_back(std::move(pe)); rsp.local_peerlist_new.push_back(std::move(pe));
if (!is_public)
rsp.local_peerlist_new.back().last_seen = 0;
} }
m_payload_handler.get_payload_sync_data(rsp.payload_data); m_payload_handler.get_payload_sync_data(rsp.payload_data);
/* Tor/I2P nodes receiving connections via forwarding (from tor/i2p daemon) // randomize so location of local inbound is not easily found
do not know the address of the connecting peer. This is relayed to them, std::shuffle(
iff the node has setup an inbound hidden service. The other peer will have rsp.local_peerlist_new.begin(), rsp.local_peerlist_new.end(), crypto::random_device{}
to use the random peer_id value to link the two. My initial thought is that );
the inbound peer should leave the other side marked as `<unknown tor host>`,
etc., because someone could give faulty addresses over Tor/I2P to get the
real peer with that identity banned/blacklisted. */
if(outgoing_to_same_zone)
rsp.local_peerlist_new.push_back(peerlist_entry{zone.m_our_address, zone.m_config.m_peer_id, std::time(nullptr)});
LOG_DEBUG_CC(context, "COMMAND_TIMED_SYNC"); LOG_DEBUG_CC(context, "COMMAND_TIMED_SYNC");
return 1; return 1;