[jira] [Commented] (PROTON-2775) pn_buffer_ensure crash due to overflow
[
https://issues.apache.org/jira/browse/PROTON-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784528#comment-17784528
]
Ken Giusti commented on PROTON-2775:
Added a check of the computed capacity and an abort() call - the crash is
happening in pn_do_transfer (see attached proton-2775-2.txt). I'm not sure how
the application will be able to prevent that.
> pn_buffer_ensure crash due to overflow
> --
>
> Key: PROTON-2775
> URL: https://issues.apache.org/jira/browse/PROTON-2775
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.40.0
>Reporter: Ken Giusti
>Priority: Major
> Attachments: proton-2775-2.txt, proton-2775.txt
>
>
> pn_buffer_ensure(pn_buffer_t *buf, size_t size) will expand the capacity of
> _buf_ to hold at least {_}size{_}.
> The implementation of pn_buffer_t maintains a capacity field that represents
> the size of of the allocated memory buffer. This capacity is implemented as a
> uint32_t type.
> The issue is that pn_buffer_ensure does not check for buffer wrap within the
> uint32_t range, which allows pn_buffer_ensure to wrap the reallocation. This
> can result in memory overflow and a crash.
> Note well that I don't think having a 2^32-1 maximum limit for a pn_buffer_t
> is wrong. I totally agree that even that size is probably overkill.
> However I think the problem is that an application can trigger the wrap since
> there is no visibility to current capacity value with the current proton API.
> E.g. aggressively call pn_link_send() when the output network connection is
> blocked by a stalled receiver.
> At a minimum proton should detect an overflow event and not blindly double
> the capacity if the requested size is within the 32 bit range.
> I would also propose that pn_buffer_ensure() invoke abort() if it is passed a
> size > UINT32_MAX. This would at minimum prevent a potential buffer overflow
> attack and at best alert the application developer that their code is buggy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2775) pn_buffer_ensure crash due to overflow
[
https://issues.apache.org/jira/browse/PROTON-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784512#comment-17784512
]
Ken Giusti commented on PROTON-2775:
Attachment proton-2775.txt contains a gdb stack dump of a crash due to
overflowed pn_buffer_t in delivery instance.
> pn_buffer_ensure crash due to overflow
> --
>
> Key: PROTON-2775
> URL: https://issues.apache.org/jira/browse/PROTON-2775
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.40.0
>Reporter: Ken Giusti
>Priority: Major
> Attachments: proton-2775.txt
>
>
> pn_buffer_ensure(pn_buffer_t *buf, size_t size) will expand the capacity of
> _buf_ to hold at least {_}size{_}.
> The implementation of pn_buffer_t maintains a capacity field that represents
> the size of of the allocated memory buffer. This capacity is implemented as a
> uint32_t type.
> The issue is that pn_buffer_ensure does not check for buffer wrap within the
> uint32_t range, which allows pn_buffer_ensure to wrap the reallocation. This
> can result in memory overflow and a crash.
> Note well that I don't think having a 2^32-1 maximum limit for a pn_buffer_t
> is wrong. I totally agree that even that size is probably overkill.
> However I think the problem is that an application can trigger the wrap since
> there is no visibility to current capacity value with the current proton API.
> E.g. aggressively call pn_link_send() when the output network connection is
> blocked by a stalled receiver.
> At a minimum proton should detect an overflow event and not blindly double
> the capacity if the requested size is within the 32 bit range.
> I would also propose that pn_buffer_ensure() invoke abort() if it is passed a
> size > UINT32_MAX. This would at minimum prevent a potential buffer overflow
> attack and at best alert the application developer that their code is buggy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
