WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
94522
Unsafe vsprintf usage in TestNetscapePlugin
https://bugs.webkit.org/show_bug.cgi?id=94522
Summary
Unsafe vsprintf usage in TestNetscapePlugin
Nate Chapin
Reported
2012-08-20 13:37:27 PDT
Original report:
http://code.google.com/p/chromium/issues/detail?id=141806
This is test-only code, so not marking it as a security issue. However, it is triggering crashes in ClusterFuzz, so it seems worth it to clean up. Using vsnprintf and a proper buffer size seems to fix the problem.
Attachments
patch
(2.63 KB, patch)
2012-08-20 13:41 PDT
,
Nate Chapin
abarth
: review+
Details
Formatted Diff
Diff
patch
(2.85 KB, patch)
2012-08-20 14:21 PDT
,
Nate Chapin
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Nate Chapin
Comment 1
2012-08-20 13:41:55 PDT
Created
attachment 159511
[details]
patch
Adam Barth
Comment 2
2012-08-20 13:47:30 PDT
Comment on
attachment 159511
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=159511&action=review
> Tools/DumpRenderTree/TestNetscapePlugIn/PluginObject.cpp:66 > char message[2048] = "PLUGIN: "; > - vsprintf(message + strlen(message), format, args); > + vsnprintf(message + strlen(message), 2040, format, args);
Why 2040 and not 2048 ? Also, these libc functions don't necessarily \0-terminate strings, so it's a good practice to explicitly write a '\0' at the end of the array after calling these functions.
Nate Chapin
Comment 3
2012-08-20 13:49:04 PDT
(In reply to
comment #2
)
> (From update of
attachment 159511
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=159511&action=review
> > > Tools/DumpRenderTree/TestNetscapePlugIn/PluginObject.cpp:66 > > char message[2048] = "PLUGIN: "; > > - vsprintf(message + strlen(message), format, args); > > + vsnprintf(message + strlen(message), 2040, format, args); > > Why 2040 and not 2048 ? Also, these libc functions don't necessarily \0-terminate strings, so it's a good practice to explicitly write a '\0' at the end of the array after calling these functions.
Because the first 8 bytes are the "PLUGIN: ", and I'm a terrible person who uses magic numbers. Any preference on how I make this clearer? Good point on the '\0'.
Thomas Sepez
Comment 4
2012-08-20 13:51:02 PDT
Comment on
attachment 159511
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=159511&action=review
>> Tools/DumpRenderTree/TestNetscapePlugIn/PluginObject.cpp:66 >> + vsnprintf(message + strlen(message), 2040, format, args); > > Why 2040 and not 2048 ? Also, these libc functions don't necessarily \0-terminate strings, so it's a good practice to explicitly write a '\0' at the end of the array after calling these functions.
Also, so long as your calling strlen(), seems like both of these values should derive from that - as in 2048 - strlen(message). But don't call strlen() twice. sizeof("PLUGIN: ") -1 is also a suitable alternate.
Adam Barth
Comment 5
2012-08-20 13:51:50 PDT
Comment on
attachment 159511
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=159511&action=review
>>> Tools/DumpRenderTree/TestNetscapePlugIn/PluginObject.cpp:66 >>> + vsnprintf(message + strlen(message), 2040, format, args); >> >> Why 2040 and not 2048 ? Also, these libc functions don't necessarily \0-terminate strings, so it's a good practice to explicitly write a '\0' at the end of the array after calling these functions. > > Because the first 8 bytes are the "PLUGIN: ", and I'm a terrible person who uses magic numbers. Any preference on how I make this clearer? > > Good point on the '\0'.
I see. Yeah, that's easy to for dumb people like me to miss. :) const size_t messageBufferSize = 2048; char message[2048] = "PLUGIN: "; messageLength = strlen(message); vsnprintf(message + messageLength, messageBufferSize - messageLength, format, args); message[messageBufferSize - 1] = '\0';
Thomas Sepez
Comment 6
2012-08-20 13:57:24 PDT
> char message[2048] = "PLUGIN: "; > messageLength = sizeof("PLUGIN: ") - 1; > vsnprintf(message + messageLength, sizeof(message) - messageLength, format, args); > message[sizeof(message) - 1] = '\0';
Adam Barth
Comment 7
2012-08-20 14:02:44 PDT
tsepez puts me to shame, as usual :)
Thomas Sepez
Comment 8
2012-08-20 14:13:49 PDT
Still not happy that we say "Plugin" twice. You should be able to tweak that string or the dimension of the buffer in one place and only one place and still have the code work. Let's see:
> char message[2048]; > static const char plugin[] = "PLUGIN: "; > memcpy(message, plugin, sizeof(plugin) - 1); > vsnprintf(message + sizeof(plugin) - 1, sizeof(message) - (sizeof(plugin) - 1), format, args); > message[sizeof(message) - 1] = '\0';
But I've not tried it.
Nate Chapin
Comment 9
2012-08-20 14:21:34 PDT
Created
attachment 159518
[details]
patch
Adam Barth
Comment 10
2012-08-20 14:32:46 PDT
Comment on
attachment 159518
[details]
patch This isn't my favorite idiom, but whatever man.
Nate Chapin
Comment 11
2012-08-20 14:35:32 PDT
(In reply to
comment #10
)
> (From update of
attachment 159518
[details]
) > This isn't my favorite idiom, but whatever man.
The way I wrote the code, or any code that matches .*printf.* ? :)
Adam Barth
Comment 12
2012-08-20 14:38:20 PDT
> The way I wrote the code, or any code that matches .*printf.* ? :)
:)
Adam Barth
Comment 13
2012-08-20 14:39:16 PDT
I think the root of the issue is that .*printf.* are so impossible to use correctly that they make the code that calls them super ugly, regardless of how it's written.
WebKit Review Bot
Comment 14
2012-08-20 16:39:54 PDT
Comment on
attachment 159518
[details]
patch Clearing flags on attachment: 159518 Committed
r126089
: <
http://trac.webkit.org/changeset/126089
>
WebKit Review Bot
Comment 15
2012-08-20 16:39:58 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug