Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#2683 closed defect (worksforme)

authority received unparseable routerstatus entry

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-auth
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

http://freehaven.net/~arma/unparseable-desc-2011-02-19
is a routerstatus entry that moria1 received as a vote but couldn't parse.

moria1 was running Tor 0.2.3.0-alpha-dev (git-0fcb677e8a33462a).

My info-level logs were

Feb 19 01:50:58.000 [warn] Error decoding identity digest "S9/Ur1aE/F4eR88uI\345lwIM\365\363(\204I\3165\226\002\216N\242S&0"
Feb 19 01:50:58.000 [info] dump_desc(): Unable to parse descriptor of type routerstatus entry. See file unparseable-desc in data directory for details.
Feb 19 01:50:58.000 [warn] Error reading network-status vote: signature does not match.
Feb 19 01:50:58.000 [warn] Couldn't parse vote: length was 997779

It looks like it doesn't record where it got the vote from?

Also, how come the unparseable-desc file is 702587 bytes but the log entry said it was 997779 bytes?

Child Tickets

Change History (14)

comment:1 Changed 8 years ago by arma

Summary: authority generates unparseable routerstatus entryauthority received unparseable routerstatus entry

comment:2 Changed 8 years ago by arma

Component: Tor RelayTor Directory Authority

comment:3 Changed 8 years ago by arma

Wow:

Mar 09 18:54:33.000 [warn] Flags line had a flag "V2@ir" not listed in known_flags.
Mar 09 18:54:33.000 [info] dump_desc(): Unable to parse descriptor of type routerstatus entry. See file unparseable-desc in data directory for details.
Mar 09 18:54:33.000 [warn] Parse error: too many p elements.
Mar 09 18:54:33.000 [warn] Error tokenizing router status
Mar 09 18:54:33.000 [warn] Unknown exit policy summary type "rejegt 1-65535".
Mar 09 18:54:33.000 [warn] Unknown exit policy summary type "rejecp 1-65535".
Mar 09 18:54:34.000 [warn] Invalid nickname "For`ModelA" in router status; skipping.
Mar 09 18:54:34.000 [warn] Invalid Bandwidth "Bandwidth=25\016p"
Mar 09 18:54:34.000 [warn] Flags line had a flag "Steble" not listed in known_flags.
Mar 09 18:54:34.000 [warn] Error parsing router address in network-status "74.207.226.599"
Mar 09 18:54:34.000 [warn] Flags line had a flag "Wtable" not listed in known_flags.
Mar 09 18:54:34.000 [warn] Parse error: missing s element.
Mar 09 18:54:34.000 [warn] Error tokenizing router status
Mar 09 18:54:35.000 [warn] ISO time "2011-03-0= 20:10:02" was unparseable
Mar 09 18:54:35.000 [warn] Error parsing time '2011-03-0= 20:10:02' [0 0]
Mar 09 18:54:35.000 [warn] Unknown exit policy summary type "renect 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999".
Mar 09 18:54:35.000 [warn] Error decoding descriptor digest "Rjnv7NShqV7dFaIxL0cloe~8Lfg"
Mar 09 18:54:35.000 [warn] Error decoding descriptor digest "FiaVBIvDs6LzQzJVuLWhc}Sfo+A"
Mar 09 18:54:35.000 [warn] Flags line had a flag "Steble" not listed in known_flags.
Mar 09 18:54:35.000 [warn] Vote networkstatus entries not sorted by identity digest
Mar 09 18:54:35.000 [warn] Couldn't parse vote: length was 961080

http://freehaven.net/~arma/unparseable-desc-2011-03-09

This one is 936400 bytes, also not 961080.

comment:4 Changed 8 years ago by arma

Are we really calling strlen on an arbitrary vote blob we got from the network?

comment:5 in reply to:  4 ; Changed 8 years ago by rransom

Priority: normalcritical

Replying to arma:

Are we really calling strlen on an arbitrary vote blob we got from the network?

Yes, even though that's the wrong way to determine the length of that particular blob. And worse, we're calling strlen on a blob some fuzzer handed us after we parse it.

Unfortunately, I don't see a nice way to check the signature before we feed a potential fuzz-bomb through our parser.

comment:6 in reply to:  description Changed 8 years ago by rransom

Status: newneeds_review

Replying to arma:

It looks like it doesn't record where it got the vote from?

The only case in which Tor does not log the source of a rejected vote is if the vote was submitted in a POST request. See bug2683a-022 ( ssh://mob@repo.or.cz/srv/git/tor/rransom.git bug2683a-022 ) for a fix for that issue.

comment:7 in reply to:  5 Changed 8 years ago by rransom

Priority: criticalnormal

Replying to rransom:

Replying to arma:

Are we really calling strlen on an arbitrary vote blob we got from the network?

Yes, even though that's the wrong way to determine the length of that particular blob. And worse, we're calling strlen on a blob some fuzzer handed us after we parse it.

strlen is the least scary operation we perform on that blob. (Yes, I know it could contain embedded NULs.)

Decreasing priority back to ‘normal’ as well, because this is hardly the scariest parser that an attacker can feed nastygrams to.

We should consider the following possible improvements, though:

  • Demote the warning messages to ‘protocol warnings’, so that the guy with the fuzzer can't spam the DAs' logs with as many junk warnings.
  • Save all blobs received from the network to disk before trying to parse them, mainly so that if someone does crash an authority, we know we have a copy of the malicious input (and we don't have to dig it out of a core dump).

comment:8 Changed 8 years ago by nickm

I'm not sure why we're even accepting votes from non-authority addresses. We could stop that too.

comment:9 Changed 8 years ago by nickm

Status: needs_reviewassigned

Your bug2683a-022 patch looks fine; merging it.

comment:10 Changed 8 years ago by nickm

Milestone: Tor: 0.2.2.x-final

comment:11 in reply to:  8 Changed 8 years ago by arma

Replying to nickm:

I'm not sure why we're even accepting votes from non-authority addresses. We could stop that too.

We should not stop that. One of the robustness features we have is that you can vote from anywhere -- so if somebody knocks moria1 off the network, I can set it up somewhere else while the ddos is happening.

comment:12 Changed 8 years ago by arma

Resolution: worksforme
Status: assignedclosed

Haven't seen any new unparseable votes since the March 9 one. Looking at the vote itself again, I can't see any other explanation but "that's somebody trying to fuzz moria1". I doubt it's a broken implementation somewhere else -- "how could anybody be *that* broken?"

Closing. Nick wants to make our general behavior in this situation better though. He just opened #3029.

comment:13 Changed 7 years ago by nickm

Keywords: tor-auth added

comment:14 Changed 7 years ago by nickm

Component: Tor Directory AuthorityTor
Note: See TracTickets for help on using tickets.