| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Largely considered attack surface nowadays. The benefit provided by %n
is completely overshadowed by the risk.
New uses of %n don't seem to be entering the C ecosystem, as static
tools flag them. And everyone points fingers at those people....
The list of programs (and libraries) which use %n is therefore finite
and shrinking. Most of the %n use comes out of the GNU ecosystem.
jca@ has convinced gnulib to fix their code (so we need to wait for
software including gnulib to make new releases).
A few libraries have moved ahead of us and become more strict. Some n
longer permit %n (for instance, andriod bionic). Others log the occurance.
Some log and abort if the output location is W|X (MacOS).
Our base tree is clean. The ports tree contains a handful during
build time, and unknown count (more) during runtime.
We would like to abort programs on any occurance of %n. Or we could
be like MacOS, aborting for W|X pages (but would need a system call
which can check that condition, and that introduces addressspace
knowledge we don't want attackers to know, and may be a poor tradeoff).
For now, we can syslog, to increase awareness, and involve more people
in the greater community to remove %n uses.
[If %n is at the end, use the *printf return value. If it occurs in
the middle, split the printf calls into multiples]
Hopefully one day, we can just abort() when %n happens. Help us get
there?
ok jca, plus naddy for ports team
|
|
|
|
|
|
|
|
| |
changes by schwarze to vfprintf.c r1.71. Cherrypicked from android:
https://github.com/aosp-mirror/platform_bionic/commit/5305a4d4a723b06494b93f2df81733b83a0c46d3
ok millert
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Over time we can repair software which performs this non-standard behaviour,
and fix bugs along the way. Let's first find out how bad the situation is
by deploying this in snapshots.
This type of logging is possible because OpenBSD syslog_r(3) -> sendsyslog(2)
is side-effect free enough to be used in the bowels of libc.
ok tedu
|
|
|
|
| |
ok and valuable input from millert@
|
|
|
|
| |
ok millert@
|
|
|
|
|
|
|
|
|
|
|
|
| |
wrapper .h files and asm labels to let internal calls resolve directly and
not be overridable or use the PLT. Then, apply that framework to most of
the functions in stdio.h, string.h, err.h, and wchar.h. Delete the
should-have-been-hidden-all-along _v?(err|warn)[cx]? symbols while here.
tests clean on i386, amd64, sparc64, powerpc, and mips64
naming feedback from kettenis@ and millert@
ok kettenis@
|
|
|
|
| |
ok martynas@, millert@, doug@
|
|
|
|
|
| |
Found by Elliott @ google
ok mpi@
|
|
|
|
|
|
|
| |
don't use disable %n ourselves. But Google's Android libc is based
on our libc.... Giving them an easy knob to disable this dangerous
feature easily make their job easier without making our job any harder.
Request from Elliott @ google
|
| |
|
| |
|
|
|
|
| |
ok deraadt@
|
|
|
|
| |
silence some warnings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
printf() and avoid calling it unless needed (i.e., when we have a
floating point value to print). This isn't a big concern currently
due to our limited locale support and current localeconv()
implementation, but it's still technically a data race and
implementing POSIX 2008 per-thread locales is likely to make it worse.
nl_langinfo() isn't guaranteed by POSIX to be thread-safe either, but
at least our current implementation is thread-safe and it's a simpler
interface to keep that way. Printing floating point values isn't
async-signal-safe anyway due to gdtoa()'s use of malloc(), so that's
not an issue.
ok deraadt, stsp, millert
|
|
|
|
| |
ok matthew dcoppa miod
|
|
|
|
| |
"Yes, go ahead then" deraadt
|
| |
|
|
Based on our vfprintf etc. implementations. Wide character parts based on
NetBSD but with lots of macros expanded. Minor bump for libc.
ok kettenis espie
|