<p>Yes. The attack was adding junk to the end of otherwise valid transactions to cause the junk to get relayed around. (as an aside, if we hadn't fixed that, segwit would have been easier to deploy...)</p>

CC BY-SA 4.0
2019-01-09T13:02:12.000Z
Interesting. Was it (in hindsight) fixed in a bad way, too rigid perhaps? Would a less hastily fix perhaps allowed for more forward-compatible flexibility?
Jannes
CC BY-SA 4.0
2019-01-09T18:32:47.817Z
Well, any fix was going to have to refuse to relay data that couldn't be validated.
G. Maxwell
CC BY-SA 4.0
2019-01-09T03:13:56.820Z
2019-01-09T03:13:56.820Z
G. Maxwell
<p>I'm surveying old Bitcoin DoS vectors and came across <a href="https://www.cvedetails.com/cve/CVE-2013-4627/" rel="nofollow noreferrer">CVE-2013-4267</a>, for which there appears to be little public information available. This thread should shed some light on this CVE.</p>

<p>There's a description in <a href="https://bitslog.wordpress.com/2013/07/18/buggy-cve-2013-4627-patch-open-new-vectors-of-attack/" rel="nofollow noreferrer">this blog post</a>:</p>

<blockquote>
  <p>Transactions are also first deserialized in order to be parsed, but they are stored “as is” in a temporary cache called MapRelay, and forwarded without being serialized again. I really don’t know why this is done. But the point is that the storage of messages as they are received leads to the possibility that an attacker creates messages much bigger than the actual transaction object contained, which, when stored in MapRelay memory, can be used to exhaust the memory of a node.</p>
</blockquote>

<p>There is also <a href="https://bitcointalk.org/index.php?topic=259101.msg2763875#msg2763875" rel="nofollow noreferrer">this relevant thread</a> which appears to say the network was under attack using this vector. </p>

<p>Based on the transaction serialization and deserialization code in ~v0.8.2, it looks like the attack may have been: add large amount of random data at the end of a valid serialized transaction. The deserializer finds what it looks for (the valid blob prefix), but appears to ignore what comes after. If a serialized transaction with random data at the end of the transaction is sent to the victim node, it will be deserialized, passed to the mem-pool and then placed in mapRelay in its full size (and then possibly forwarded further, which seems like a pretty powerful attack vector).</p>

<p>So: was the attack described by CVE-2013-4267 based on adding random data at the end of (valid) serialized transaction data? </p>

<transactions><attack>
Serialized transaction bigger than the actual transaction object? CVE-2013-4627
anon2328
# Serialized transaction bigger than the actual transaction object? CVE-2013-4627

(Asked by: username_0 on 2019-01-08)

I'm surveying old Bitcoin DoS vectors and came across [CVE-2013-4267](https://www.cvedetails.com/cve/CVE-2013-4627/), for which there appears to be little public information available. This thread should shed some light on this CVE.

There's a description in [this blog post](https://bitslog.wordpress.com/2013/07/18/buggy-cve-2013-4627-patch-open-new-vectors-of-attack/):

> Transactions are also first deserialized in order to be parsed, but they are stored “as is” in a temporary cache called MapRelay, and forwarded without being serialized again. I really don’t know why this is done. But the point is that the storage of messages as they are received leads to the possibility that an attacker creates messages much bigger than the actual transaction object contained, which, when stored in MapRelay memory, can be used to exhaust the memory of a node.

There is also [this relevant thread](https://bitcointalk.org/index.php?topic=259101.msg2763875#msg2763875) which appears to say the network was under attack using this vector.

Based on the transaction serialization and deserialization code in ~v0.8.2, it looks like the attack may have been: add large amount of random data at the end of a valid serialized transaction. The deserializer finds what it looks for (the valid blob prefix), but appears to ignore what comes after. If a serialized transaction with random data at the end of the transaction is sent to the victim node, it will be deserialized, passed to the mem-pool and then placed in mapRelay in its full size (and then possibly forwarded further, which seems like a pretty powerful attack vector).

So: was the attack described by CVE-2013-4267 based on adding random data at the end of (valid) serialized transaction data?

**Tags:** transactions, attack


---

## 1 answers

### Answer by username_1 on 2019-01-09. Score: 2

Yes. The attack was adding junk to the end of otherwise valid transactions to cause the junk to get relayed around. (as an aside, if we hadn't fixed that, segwit would have been easier to deploy...)

> **Comments:**
> **username_2**: Interesting. Was it (in hindsight) fixed in a bad way, too rigid perhaps? Would a less hastily fix perhaps allowed for more forward-compatible flexibility?  
> **username_1**: Well, any fix was going to have to refuse to relay data that couldn't be validated.  

---

