| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ACKs to fragmented notices keep the multiuid field, but multipart becomes "".
This is interpreted as 0/z_message_length. This means ACKs to non-initial
fragments look like an initial fragment from the multipart field, but not when
checking uid == multiuid. The result is that they get smashed when passing
through reassembly.
6e8ec12b0ba9d476e065957028e4cf9cf69d6ac2 addressed this. For SERVACKs and
SERVNAKs, it drops all but the initial ones (uid == multipart) on the floor. It
ignores the problem for HMACKs. Normally ZSendPacket blocks on the HMACK before
sending each successive fragment, so there's no opportunity for them to
collide. But if calling ZSrvSendNotice with a custom send_function that doesn't
block, the HMACKs can smash into each other depending on timing.
Instead, fix it by using z_uid instead of z_multiuid as the multiuid key. For
compatibility, keep the SERVACK dropping behavior. (I'd like to get all the
SERVACKs too, but potentially that'll confuse clients somewhat.)
|
| |
|
|
| |
May as well put it in .rodata
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When Z_ReadWait receives a packet which doesn't start with a zephyr
version header, it considers the packet to be "obviously non-zephyr".
Such packets are discarded and, previously, caused Z_ReadWait to return
ZERR_NONE. Unfortunately, this can cause things to block for up to 60s
when a caller was expecting a non-blocking call to pick up a new packet
if there is one.
This changes Z_ReadWait to return ZERR_BADPKT in this situation,
eliminating the potential wait.
This fixes #100
|
| |
|
|
| |
This fixes #94
|
| |
|
|
|
|
| |
This can't get subs in the athena realm.
This reverts commit b92153fac201a9a22779817be5f2375f7cf754fc.
|
| |
|
|
| |
This fixes #94
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminate compiler warnings due to various issues (listed below). This
allows Zephyr to build cleanly under GCC versions ranging from 4.1.0 to
4.7.2 with all of the options shown below:
-g -O2 -Wall -Werror
-Wno-deprecated-declarations
-Wmissing-declarations
-Wpointer-arith
-Wstrict-prototypes
-Wshadow
-Wextra
-Wno-missing-field-initializers
-Wno-unused-parameter
and, on recent versions, -Wunreachable-code
Test builds were done
- On Ubuntu 12.10 (Quantal Quetzal) using both MIT Kerberos 1.10.1 and
Heimdal 1.6, without krb4 and both with and without C-Ares and Hesiod
- On Fedora 14 using Heimdal 0.6, without C-Ares or Hesiod and both
with and without krb4 (KTH Kerberos 1.3rc2)
- On Fedora Core 3, Fedora Core 5, Fedora 7, and Fedora 10, using
Heimdal 0.6 and without C-Ares, Hesiod, or krb4
It also allows clean builds on Solaris 10 under the Sun Studio 12 (9/07)
C compiler with the following options:
-g -fd -v -errfmt -errhdr=%user -errtags=yes -errwarn=%all
-erroff=E_OLD_STYLE_FUNC_DECL,E_ENUM_TYPE_MISMATCH_ARG,E_ARG_INCOMPATIBLE_WITH_ARG
... and under Solaris 9 with the Sun Forte 7 (3/02) C compiler with the above
options and -erroff=E_FUNC_HAS_NO_RETURN_STMT. Solaris builds were done
with Heimdal 0.6 and without C-Ares, Hesiod, or krb4.
The following types of issues are addressed in this change:
- Parameters and local variables with the same names as library functions
- Parameters and local variables with the same names as globals
- Declarations for exported global variables missing from headers
- Prototypes for exported functions missing from headers
- Missing 'static' on functions that shouldn't be exported
- Old-style function declarations
- Duplicate declarations
- Type mismatches
- Unused variables and functions
- Uninitialized variables
- Forward references to enums
- Necessary header files not included
- Violations of the aliasing rules, where GCC was able to detect them
- Missing braces on if blocks that might be empty
- Attempts to do pointer arithmetic on pointers of type void *, which
is not permitted in standard C.
- An attempt to pass a function pointer via a void * parameter, which is
not permitted in standard C. Instead, we now pass a pointer to a
structure, which then contains the required function pointer.
- Unnecessary inclusion of <krb5_err.h>, which is already included by
<krb5.h> when the former exists, and might not be protected against
double inclusion, depending on which com_err was used.
- Missing include of <com_err.h>, which was masked by the fact that it is
included by headers generated by e2fsprogs compile_et
- Use of com_err() with a non-constant value in place of the format string,
which in every case was a fixed-size buffer in which a message was built
using sprintf(!). Both the calls to sprintf and the fixed-size buffers
have been removed, in favor of just letting com_err() do the formatting.
- Various cases where X library functions expecting a parameter of type
wchar_t * were instead passed a parameter of type XChar2b *. The two
types look similar, but are not the same and are _not_ interchangeable.
- An overly-simplistic configure test which failed to detect existence of
<term.h> on Solaris, due to not including <curses.h>.
- Using the wrong type for the flags output of krb5_auth_con_getflags()
when building against Heimdal. A configure test is added to detect
the correct type.
|
| | |
|
| |
|
|
|
|
|
| |
The result of Z_krb5_verify_cksum is supposed to be nonzero on success and
0 on failure. But if krb5_crypto_init() failed, we were returning the
resulting error code, effectively accepting any checksum, when instead we
should reject the checksum since we cannot verify it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From -c shadow on 15-Nov-2011, discussing a problem where some notices
received from other realms were causing clients to crash:
So, the packet that crashed my client had extra garbage beyond what
should have been the end of the packet. So z_multinotice was 0/61,
but the packet was longer than 61. Which means the logic that should
have treated this as an unfragmented notice (because partof ==
z_message_len) did not trigger.
So a holelist gets created, with enough storage for partof, and then
Z_AddNoticeToEntry is called to copy z_message_len (> partof) bytes
into it.
So, I don't know why your client, or the server, or something, is sending
packets longer than the message length, but I don't think I actually want
to just discard those, because then "legitimate" messages would vanish.
Instead, if part + notice->z_message_len > partof, I just want to ignore
the extra.
|
| |
|
|
|
|
|
| |
Have Z_FormatRawHeader call Z_ZcodeFormatRawHeader to reduce duplication
and error. Z_FormatRawHeader was previously adding headers 17 and 18
unconditionally, which was not proper for a server forwarding an unauth
message.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Since these are constants used in the protocol be explicit about what values
the C compiler is assigning them, and that they can't be arbitrarily
rearranged.
Also, since we were promising strings for describing them in zephyr.h
actually define the array.
|
| | |
|
| |
|
|
| |
and it breaks the build when there isn't a utmp.h
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per Nelson Elhage:
find_or_insert_uid sorts 'buffer' by the uid, which is a
remotely-provided field. However, in order to expire uids, it does:
while (num && (now - buffer[start % size].t) > CLOCK_SKEW)
start++, num--;
start %= size;
i.e. starts from the start of the queue and goes until it finds
something sufficiently new. Since the queue ordering is
attacker-controlled, we can send an arbitrarily-long sequence of
decreasing uids, consuming memory and forcing the client into an
ever-growing quadratic loop to insert them at the beginning.
--
Solve this by not keeping the buffer sorted; just tack the incoming
uids on the end. This way an attacker can make us keep five minutes
worth of UIDs, but only five minutes, and also anecdotally a client
under attack spends all of its CPU sort uids.
|
| |
|
|
|
|
|
| |
(The time used to be set before the bounds check, so one could
potentially get an accumulation of packets in the queue without
timestamps that could never be assembled into a full notice; thanks to
nelhage@mit.edu for noticing.)
|
| |
|
|
| |
(thanks to nelhage@mit.edu for noticing this)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
keyusage stuff
such that it actually works.
|
| | |
|
| |
|
|
|
|
|
| |
that we don't
inadvertantly alter the checksum.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
was being sent in an extra header field. This worked about as well as you
might expect. Fortunately we happened to be putting an address in header
field 18 anyway, so backwards compatibility should be relatively painless.
I don't know which approach is a more egregious hack, but this change
at least nets us four less lines of code, which is obviously good, right?
Oh, and while we're at it, if the sa_family isn't set on the sender address,
just cringe and set it to AF_INET.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
get non-Zephyr packets from somewhere. We've seen it happen on Linux
with getting rx packets.
|
| |
|
|
|
| |
(in particular, this makes attach eventually time out when trying to get
filsrv subs if the zhm or zephyr servers aren't responding).
|
| | |
|
| |
|
|
|
|
| |
having a special function in Zinternal.c. More importantly, do a better
job of finding the local address by using getsockname() on a connected
UDP socket.
|
| | |
|
| |
|
|
| |
have a macro for it.
|
| | |
|
| |
|
|
| |
detailed change information.
|
| |
|
|
|
| |
cause the zephyr servers to spew errors.
./
|
| | |
|
David Benjamin
Jeffrey Hutzelman
Karl Ramm
Chaskiel Grundman
Karl Ramm
Greg Hudson
Dan Winship