aboutsummaryrefslogtreecommitdiffstats
path: root/common/argparse.c
diff options
context:
space:
mode:
authorWerner Koch <[email protected]>2015-01-28 19:32:28 +0000
committerWerner Koch <[email protected]>2015-01-28 19:32:28 +0000
commit382ba4b137b42d5f25a7e256bb7c053ee5ac7b64 (patch)
tree023c12a8a829bb6f56f72d4b8204aca97ab6869b /common/argparse.c
parentgpg: Fix buffering problem in --list-config. (diff)
downloadgnupg-382ba4b137b42d5f25a7e256bb7c053ee5ac7b64.tar.gz
gnupg-382ba4b137b42d5f25a7e256bb7c053ee5ac7b64.zip
gpg: Limit the size of key packets to a sensible value.
* g10/parse-packet.c (MAX_KEY_PACKET_LENGTH): New. (MAX_UID_PACKET_LENGTH): New. (MAX_COMMENT_PACKET_LENGTH): New. (MAX_ATTR_PACKET_LENGTH): New. (parse_key): Limit the size of a key packet to 256k. (parse_user_id): Use macro for the packet size limit. (parse_attribute): Ditto. (parse_comment): Ditto. -- Without that it is possible to force gpg to allocate large amounts of memory by using a bad encoded MPI. This would be an too easy DoS. Another way to mitigate would be to change the MPI read function to allocate memory dynamically while reading the MPI. However, that complicates and possibly slows down the code. A too large key packet is in any case a sign for broken data and thus gpg should not use it. Reported-by: Hanno Böck GnuPG-bug-id: 1823 Signed-off-by: Werner Koch <[email protected]>
Diffstat (limited to 'common/argparse.c')
0 files changed, 0 insertions, 0 deletions