vtls: fix potential version string overflow by danielgustafsson · Pull Request #3863 · curl/curl

danielgustafsson · 2019-05-10T19:45:22Z

In Curl_multissl_version() it was possible to overflow the passed in buffer if the generated version string exceeded the size of the buffer. Fix by inverting the logic, and also make sure to not exceed the local buffer during the string generation.

Reported-by: nevv on HackerOne/curl

jay · 2019-05-10T21:49:52Z

You'll have to account for each time p is incremented. How about

if(current != selected) { char *p = backends; char *end = backends + sizeof(backends); int i; selected = current; for(i = 0; available_backends[i] && p < end - 4; i++) { if(i) *(p++) = ' '; if(selected != available_backends[i]) *(p++) = '('; p += available_backends[i]->version(p, end - p - 2); if(selected != available_backends[i]) *(p++) = ')'; } *p = '\0'; total = p - backends; }

Also I suggest increase it to like 1k size, 200 seems low for multiple versions.

also what is supposed to happen here if(current==selected)?

If we need to increase the backends buffer, or perhaps independently of that, we should also increase the version and the ssl_version buffers that are used to get this output (in lib/version.c) - both of them are probably in the smaller end if someone builds a curl with all possible TLS backends enabled (not sure exactly how many and which that might be).

also what is supposed to happen here if(current==selected)?

It's keeping the buffer cached in case the current TLS backend hasn't changed between calls, as the selectdt backend is printed differently from the rest.

You'll have to account for each time p is incremented.

Good catch, fixing.

Also I suggest increase it to like 1k size, 200 seems low for multiple versions.

I'm not sure 200 characters is too low, and 1k seems like excessive stack usage, but there are definitely buffers in the version printing which needs to get bumped. That's will be a separate PR though.

I would imagine 200 should be enough. If you manage to build with 6 backends, that makes it 33 bytes per backend, and I don't think any backend uses that much. 8 backends give 25 bytes each, probably also plenty enough.

I doubt we can build with more than 8, if even that...

Good catch, fixing.

I've added p += available_backends[i]->version(p, end - p - 2); since it wasn't in the fix. Technically if bytes written returned is always going to be less than the count passed (eg version(foo, 5) and therefore the max it will return is 4 bec it accounts for the null) you only need to subtract 1 but I think subtracting 2 makes the intention clearer.

jay · 2019-05-10T22:23:13Z

In Curl_multissl_version() it was possible to overflow the passed in buffer if the generated version string exceeded the size of the buffer. Fix by inverting the logic, and also make sure to not exceed the local buffer during the string generation. Closes #xxxx Reported-by: nevv on HackerOne/curl

danielgustafsson · 2019-05-11T19:53:40Z

Pushed a rebased fixup version with the comments addressed.

When running a multi TLS backend build the version string needs more buffer space. Make the internal ssl_buffer stack buffer match the one in Curl_multissl_version() to allow for the longer string. For single TLS backend builds there is no use in extended to buffer. This is a fallout from curl#3863 which fixes up the multi_ssl string generation to avoid a buffer overflow when the buffer is too small.

curl#3863 (comment)

danielgustafsson · 2019-05-13T18:33:32Z

Squashed and pushed this to master, thanks for review!

When running a multi TLS backend build the version string needs more buffer space. Make the internal ssl_buffer stack buffer match the one in Curl_multissl_version() to allow for the longer string. For single TLS backend builds there is no use in extended to buffer. This is a fallout from #3863 which fixes up the multi_ssl string generation to avoid a buffer overflow when the buffer is too small. Closes #3875 Reviewed-by: Daniel Stenberg <daniel@haxx.se>

dscho · 2019-05-23T19:06:55Z

      if(selected != available_backends[i])
        *(p++) = '(';
-      p += available_backends[i]->version(p, backends + sizeof(backends) - p);
+      p += available_backends[i]->version(p, end - p - 2);


Shouldn't this be an end - p > 2 ? end - p - 2 : 0? The second parameter is declared as size_t, i.e. unsigned...

end - p is always > 2 at that point, refer to the loop condition p < (end - 4), then after that p can be incremented twice before end - p - 2

Right, unless I'm missing something @jay is right, the current coding should be safe (but it might warrant a comment explaining it).

I find adding a comment to be unnecessary I think it's pretty straightforward.

Well, one could just write the loop condition as ...&& (end - p) > 4 and it'd be easier to read

I find adding a comment to be unnecessary I think it's pretty straightforward.

So you're saying that I am dumb. Because I did not see that.

I don't take this personally, coming from you, as I had pleasant and productive interactions with you in the past, but I wonder whether you realized how unfortunate a reaction your comment would elicit (and I think it is pretty obvious that it would do exactly that). Might want to be more careful.

In short: while it might be obvious to you, now, I think that my comment is testament enough to give evidence to the contrary. And who knows, maybe you yourself will belong into the same "wait, what?" camp in 6 months from now.

I'm in @dscho's corner here. When I first saw the question here about this line of code it was not immediately obvious to me that it was right. A comment could've remedied that both for @dscho and for me. For those who don't need the comment, it won't hurt (much) anyway.

I find adding a comment to be unnecessary I think it's pretty straightforward.

So you're saying that I am dumb. Because I did not see that.

I don't take this personally, coming from you, as I had pleasant and productive interactions with you in the past, but I wonder whether you realized how unfortunate a reaction your comment would elicit (and I think it is pretty obvious that it would do exactly that). Might want to be more careful.

In short: while it might be obvious to you, now, I think that my comment is testament enough to give evidence to the contrary. And who knows, maybe you yourself will belong into the same "wait, what?" camp in 6 months from now.

Whoa I may not be very tactful but don't put words in my mouth. I figured you misread the code, like I do occasionally. I would've shared my opinion even if that wasn't the case. If you had a different opinion that's all you needed to say in your reply.

Anyway, clearly my opinion of it being straightforward is not in favor. Someone propose a comment so we can put this to bed. /* end - p is > 2 at this point */ ?

bagder approved these changes May 10, 2019

View reviewed changes

jay reviewed May 10, 2019

View reviewed changes

danielgustafsson force-pushed the dg-sslbuf_stackoverflow branch from 8bbfa52 to 629f4c6 Compare May 11, 2019 19:53

danielgustafsson mentioned this pull request May 12, 2019

version: make ssl_version buffer match for multi_ssl #3875

Closed

squashme: ensure room for )\0

38f17e7

curl#3863 (comment)

danielgustafsson closed this in b4bb920 May 13, 2019

dscho reviewed May 23, 2019

View reviewed changes

lock Bot locked as resolved and limited conversation to collaborators Aug 24, 2019

Uh oh!

Uh oh!

Conversation

danielgustafsson commented May 10, 2019

Uh oh!

jay May 10, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danielgustafsson commented May 11, 2019

Uh oh!

danielgustafsson commented May 13, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jzakrzewski May 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants

jay May 10, 2019 •

edited

Loading

jzakrzewski May 24, 2019 •

edited

Loading