Re: [Full-disclosure] 0day: PDF pwns Windows
But then there is the important concept of the private 0day, a new vulnerability that a malicious person has but has not used yet. But the point is there is no such thing as a 0day *vulnerability; there's a 0day exploit, an exploit in the wild before the vulnerability id discovered. By claiming all new vulnerabilities are 0day the term becomes completely meaningless; by your reasoning there is no such thing as a non-0day vulnerabillity; well, the next they it's no longer a 0day vulnerability but the funny thing is that everybody keeps calling it that. When a vulnerability is discovered you cannot be sure no-one found it before; the only thing you can ever be sure of whether at that point an exploit was detected in the wild. I don't like this chain of logic. Whether a new vulnerability is an 0day or not depends entirely too much on the disclosure process, with funky race conditions in there. But by your reasoning *all* vulnerabilities are 0day at some point; or is the only exception those found by the vendor itself? Rather, I just treat 0day as a synonym for new vulnerability and don't give a hoot about the alleged intentions of whoever discovered it. What makes it an 0 day is that whoever is announcing it is first to announce it in public. You could only invalidate the 0day claim by showing that the same vulnerability had previously been disclosed by someone else. The point is that it is not supposed to be moniker for vulnerabilities; it's a moniker for exploits. In any other context it does not make sense. Specifically considering that 0-day exploit is the only definition which holds meaning with respect to a particular exploit over time. An exploit which existed before the vulnerability was publicly known. But a 0 day vulnerability is meaningless as a definition; it applies to a vulnerability for exactly 24 hours and then is meaningless. ALL vulnerabilities were discovered at some point and had their 24 hours of 0 day fame by your definition. It just does not make sense. Casper ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Solaris telnet vulnberability - how many on your network?
The simplest possible fix on such short notice: http://cvs.opensolaris.org/source/diff/onnv/onnv-gate/usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c ?r2=3629r1=2923 Casper How about just uncommenting the following from /etc/default/login # If CONSOLE is set, root can only login on that device. # Comment this line out to allow remote login by root. # CONSOLE=/dev/console Not a fix to be sure, but at least prevents a remote login. That is the default; and preventing root logins does not prevent other logins. svcadm disable telnet is the best fix (and there's really no reason to enable it) Casper ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Solaris telnet vulnberability - how many on your network?
Am I missing something? This vulnerability is close to 10 years old. It was in one of the first versions of Solaris after Sun moved off of the SunOS BSD platform and over to SysV. It has specifically to do w= ith how arguments are processed via getopt() if I recall correctly. You're confused with AIX/Linux Solaris did not have the -f option in login until much later. Casper ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Solaris telnet vulnberability - how many on your network?
Yeah, a backdoor is a remote possibility. But it's also an arbitrary and needlessly complex one. Maybe it's a nefarious plot by our UFO-appointed shadow government, but chances are, it's not (they have better things to do today). And one which was too easy to discover; real back doors are better masquared as buffer overflows you might not chance upon. Casper ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Solaris telnet vulnberability - how many on your network?
On Tue, 13 Feb 2007 [EMAIL PROTECTED] wrote: Am I missing something? This vulnerability is close to 10 years old. It was in one of the first versions of Solaris after Sun moved off of the SunOS BSD platform and over to SysV. It has specifically to do w= ith how arguments are processed via getopt() if I recall correctly. You're confused with AIX/Linux Solaris did not have the -f option in login until much later. Hi Casper. While we have you here, any idea on when Sun will be patching this issue? Now, follow the links from http://sunsolve.sun.com/tpatches Casper ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
So you are basically saying open source free software can't be trusted to hold high standards or be reliable or secure if I don't pay for it? No, he is saying that *their* high standards are not necesarily *your* high standards. And that *they* get to define the rules with which they publish their advisories; many people are fine with the way they do it so why should they listen to *you*? Casper ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: readdir_r considered harmful
In practice, you're correct. In theory, however, consider the following code path. THREAD 1 THREAD 2 ---- DIR *d1 = opendir(dir1); DIR *d2 = opendir(dir2); dent1 = readdir(dir1); dent2 = readdir(dir2); use(dent1); In most implementations, dent1 != dent2. HOWEVER, there is no guarantee that they will not both point to the same statically allocated buffer, and some implementations may do so. For example, this is why ctime_r exists: ctime returns a pointer to a statically allocated buffer, and hence is not thread safe. The standard actually guarantees that the static storage is associated with the specific directory STREAM. So a system on which dent1 and dent2 point to the same buffer and reads from one stream affect the buffer returned by reads from another stream are not POSIX compliant. See: http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html The pointer returned by readdir() points to data which may be overwritten by another call to readdir() on the same directory stream. This data is not overwritten by another call to readdir() on a different directory stream. But is also goes on to say: The readdir() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. which is the one thing I like POSIX to fix for thread safe implementations. Casper ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: readdir_r considered harmful
On 11/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I don't see how that is relevant; the typical use of readdir() is as follows:
DIR *dirp = opendir(name);
while ((dent = readdir(dirp)) != NULL) {
...
}
closedir(dirp);
Nothing other threads do with readdir() on different dirp's will influence
what dent points to.
The issue is multiple threads using the same DIR.
No, it isn't. I certainly limited the scope of my contribution to
single threads reading from a DIR.
All the 80-odd uses of readdir_r() in the Solaris core source code,
all can (and should) be replaced with readdir(). All have a single
thread reading and reusing the same struct dirent, so readdir()
could be used in POSIXly correct fashion if the following sentence
in the open group's manual page was not present:
The readdir() function need not be reentrant. A function that is not
required to be reentrant is not required to be thread-safe.
I believe that this is an error in POSIX; when threadedness was added
the manual page could have been changed to indicate that a single
thread using the above idiom was safe.
Had they done so, we would never have had to use readdir_r() and progammers
would not have introduced bugs in the (mis)use of pathconf, over allocating,
etc.
I would be interested in seeing any real-world use of readdir_r() in
a context where readdir_r() is required (multiple threads reading from
a single DIR *).
Casper
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: readdir_r considered harmful
Then you never really understood the implementation, seems. Of course
all implementations keep the content of the directory as read with
getdents or so in the DIR descriptor. But it is usually not the case
that the whole content fits into the buffer allocated. One could, of
course, resize the buffer to fit the content of the directory read,
even if this means reserving hundreds or thousands of kBs. But this
is not how most implementations work.
I don't see how that is relevant; the typical use of readdir() is as follows:
DIR *dirp = opendir(name);
while ((dent = readdir(dirp)) != NULL) {
...
}
closedir(dirp);
Nothing other threads do with readdir() on different dirp's will influence
what dent points to.
I have *never* seen a program where multiple threads read from a single
dirp; and I can't image the use.
Instead implementations keep work similar to every buffered file I/O
operation. But this means that buffer content is replaced. If this
happens and some thread uses readdir() instead of readdir_r(), the
returned string pointer suddenly becomes invalid since it points to
memory which has been replaced.
Yes, the next call to readdir() *on the same dirp* may change what
the previous call; but that's completely irrelevant for most uses
of readdir().
Of course, an application may want to save all readdir() return values,
but that is completely orthogonal to threads; there is no reason
why the POSIX *thread* specification includes readdir_r().
Next time, before you make such comments, ask Don Cragun to explain
things to you.
Next time before you mail, you might want to engage your brain.
There is NO reason for a thread-safe library to use readdir_r() over
readdir(), with common readdir() implementations.
Casper
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: readdir_r considered harmful
The Austin Group should amend POSIX and the SUS in one or more of the following ways: 1. Standardise the dirfd function from BSD and recommend its use in determining the buffer size for readdir_r. 2. Specify a new variant of readdir in which the buffer size is explicit and the function returns an error code if the buffer is too small. 3. Specify that NAME_MAX must be defined as the length of the longest name that can be used on any filesystem. (This seems to be what many or most implementations attempt to do at present, although POSIX currently specifies otherwise.) Why not: 4. Require the readdir() implementation to use state local to dirp. I've never understood the rationale behind readdir_r; it's like someone went through the manual looking for pointers to static locations and defined new functions with _r for each of them, suspending thinking. But perhaps people can look at how their readdir() implementations behave. The Solaris implementation appears to be unshared dirp safe. Casper ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: (ICMP attacks against TCP) (was Re: HPSBUX01137 SSRT5954
There are still some radio links with MTUs of 296 bytes. Go search with googlepeople still actively use smaller MTUs. What do you do? Where do you draw the line in the sand? Well, the minimum requirement for you must be able to reassemble this is 576; so you use PMTU until you go as low as 576 at which point you stop using the DF bit. Casper ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
