aboutsummaryrefslogtreecommitdiff
path: root/Makefile
diff options
context:
space:
mode:
authorAvi Halachmi (:avih) <avihpit@yahoo.com>2019-10-16 11:17:23 +0300
committerHiltjo Posthuma <hiltjo@codemadness.org>2019-11-10 22:45:54 +0100
commitea4d933ed9d8ce16699c84892a29e070c70b2eb9 (patch)
tree5ce9d2d5de969219b0fdbed81bb86f8d28b92876 /Makefile
parent83866428de031300eab03fbb116bcf7d2b1d4f60 (diff)
downloadst-ea4d933ed9d8ce16699c84892a29e070c70b2eb9.tar.gz
st-ea4d933ed9d8ce16699c84892a29e070c70b2eb9.tar.bz2
base64dec: don't read out of bounds
Previously, base64dec checked terminating input '\0' every 4 calls to base64dec_getc, where the latter progressed one or more chars on each call, and could read past '\0' in the way it was used. The input to base64dec currently comes only from OSC 52 escape seq (copy to clipboard), and reading past '\0' or even past the buffer boundary was easy to trigger. Also, even if we could trust external input to be valid base64, there are different base64 standards, and not all of them require padding to 4 bytes blocks (using trailing '=' chars). It didn't affect short OSC 52 strings because the buffer is initialized to 0's, so typically it did stop within the buffer, but if the string was trimmed to fit (the buffer is 512 bytes) then it did also read past the end of the buffer, and the decoded suffix ended up arbitrary. This patch makes base64dec_getc not progress past '\0', and instead produce fake trailing padding of '='. Additionally, at base64dec, if padding is detected at the first or second byte of a quartet, then we identify it as invalid and abort (a valid quartet has at least two leading non-padding bytes).
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions