If you use sprintf()
or vsprintf()
, you need to allocate a buffer first, and you need to be sure that the buffer is large enough to contain what sprintf writes. Otherwise sprintf()
will happily overwrite whatever memory lies beyond the end of the buffer.
char* x = malloc(5 * sizeof(char));
// writes "123456" +null but overruns the buffer
sprintf(x,"%s%s%s", "12", "34", "56");
... writes the '6' and the terminating null
beyond the end of the space allocated to x
, either corrupting some other variable, or causing a segmentation fault.
If you're lucky, it will trample on memory in-between allocated blocks, and will do no harm -- this time. This leads to intermittent bugs -- the hardest kind to diagnose. It's good to use a tool like ElectricFence that causes overruns to fail-fast.
A non-malicious user who provides an overlong input, could cause the program to behave in unexpected ways. A malicious user could exploit this as a way to get their own executable code into the system.
One guard against this is to use snprintf()
, which truncates the string to the maximum length you supply.
char *x = malloc(5 * sizeof(char));
int size = snprintf(x, 5, "%s%s%s", "12", "34", "56"); // writes "1234" + null
The return value size
is the length that would have been written if space was available -- not including the terminating null.
In this case, if size
is greater than or equal to 5 then you know that truncation occurred - and if you didn't want truncation, you could allocate a new string and try snprintf()
again.
char *x = malloc(BUF_LEN * sizeof(char));
int size = snprintf(x, 5, "%s%s%s", "12", "34", "56");
if (size >= BUF_LEN) {
realloc(&x,(size + 1) * sizeof(char));
snprintf(x, size + 1 , "%s%s%s", "12", "34", "56");
}
(That's a pretty naive algorithm, but it illustrates the point. There may yet be bugs in it, which further illustrates the point -- this stuff is easy to screw up.)
asprintf()
does this in one step for you - calculates the length of the string, allocates that amount of memory, and writes the string into it.
char *x;
int size = asprintf(&x, "%s%s%s", "12", "34", "56");
In all cases, once you've finished with x
you need to release it, or you leak memory:
free(x);
asprintf()
is an implicit malloc()
, so you have to check it worked, just as you would with malloc()
or any other system call.
if (size == -1 ) {
/* deal with error in some way */
}
Note that asprintf()
is part of the GNU and BSD extensions to libc - you can't be sure it will be available in every C environment. sprintf()
and snprintf()
are part of the POSIX and C99 standards.
Best Answer
One very quick way around this is, when you're viewing the "Your connection is not private" screen:
typebadidea
type
thisisunsafe
(credit to The Java Guy for finding the new passphrase)That will allow the security exception when Chrome is otherwise not allowing the exception to be set via clickthrough, e.g. for this HSTS case.
This is only recommended for local connections and local-network virtual machines, obviously, but it has the advantage of working for VMs being used for development (e.g. on port-forwarded local connections) and not just direct localhost connections.
Note: the Chrome developers have changed this passphrase in the past, and may do so again. If
badidea
ceases to work, please leave a note here if you learn the new passphrase. I'll try to do the same.Edit: as of 30 Jan 2018 this passphrase appears to no longer work.If I can hunt down a new one I'll post it here. In the meantime I'm going to take the time to set up a self-signed certificate using the method outlined in this stackoverflow post:How to create a self-signed certificate with openssl?Edit: as of 1 Mar 2018 and Chrome Version 64.0.3282.186 this passphrase works again for HSTS-related blocks on .dev sites.Edit: as of 9 Mar 2018 and Chrome Version 65.0.3325.146 the
badidea
passphrase no longer works.Edit 2: the trouble with self-signed certificates seems to be that, with security standards tightening across the board these days, they cause their own errors to be thrown (nginx, for example, refuses to load an SSL/TLS cert that includes a self-signed cert in the chain of authority, by default).
The solution I'm going with now is to swap out the top-level domain on all my .app and .dev development sites with .test or .localhost. Chrome and Safari will no longer accept insecure connections to standard top-level domains (including .app).
The current list of standard top-level domains can be found in this Wikipedia article, including special-use domains:
Wikipedia: List of Internet Top Level Domains: Special Use Domains
These top-level domains seem to be exempt from the new https-only restrictions:
See the answer and link from codinghands to the original question for more information:
answer from codinghands