IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Previously if there was a conflict, but the incoming object would still
win, this was not marked as a rename, and so inheritence was not done.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12497
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
When contending a WRITE with an existing READ, the contender puts
himself into the exclusive slot, waiting for the READers to go
away. If the async lock request is canceled before we got the lock, we
need to remove ourselves again. This is done in the destructor of the
g_lock_lock_state. In the successful case, the destructor needs to go
away.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Sun Dec 22 18:57:17 UTC 2019 on sn-devel-184
This walks different code paths in the subsequent locker. And the one
that we did not test so far is in fact buggy
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This simply matches the behaviour from before e7b1acaddf2ccc7de0301cc67f72187ab450e7b5
when the logic for a trailing . was added. This matches what is added in
the dnsRecord attribute for a name of "." over the dnsserver RPC
management interface and is based on what Windows does for that name
in (eg) an MX record.
No a security bug because we use talloc and so name will be just the
end of the talloc header.
Credit to OSS-Fuzz
Found using the fuzz_ndr_X fuzzer
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Fri Dec 20 11:33:52 UTC 2019 on sn-devel-184
Ensure that the '-lock' files for the dns partitions as well as the data
files are linked when running
samba_dnsupgrade --dns-backend=BIND9_DLZ
failure to create these links can cause corruption of the corresponding
data file.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14199
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Add tests to check that the '-lock' files for the dns partitions as well as
the data files are linked when running
samba_dnsupgrade --dns-backend=BIND9_DLZ
failure to create these links can cause corruption of the corresponding
data file.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14199
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Credit to OSS-Fuzz
Found using the ndr_fuzz_X target.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Found by Douglas Bagnall using Hongfuzz and the new fuzz_ndr_X
fuzzer.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13876
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
The set was within the switch, the get was before the switch.
The difference is shown when there is an empty default element.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13876
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Found by Douglas Bagnall using Hongfuzz and the new fuzz_ndr_X
fuzzer.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13876
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
There are two concerns here, assuming the attacker can place arbitary values
in a dnsProperty attribute over LDAP (eg is a DNS administrator).
This comes from the fact that id is used as the switch value at the C layer
but at the NDR layer the wDataLength value is considered first.
One concern is that a pull/push round-trip could include server memory:
The previous switch_is() behaviour could store the server memory back
into the attribute.
However this pattern of pull/push only happens in ndrdump and fuzzing tools, as
dnsserver_db_do_reset_dword() operates only on the uint32/bitmap union
arms, and fully initialises those.
The other is that a pull of the attacker-supplied value could
cause the server to expose memory.
This would be over the network via DNS or the RPC dnsserver protocols.
However at all times the ndr_pull_struct_blob is passed zeroed memory.
The final concern (which fuzz_ndr_X found) is that in the ndr_size_dnsPropertyData()
the union descriminent is only id.
This has no impact as only zeroed memory is used so there will be a
zero value in all scalars, including data->d_ns_servers.AddrArray.
Therefore the server will not crash processing the attacker-supplied blob
[MS-DNSP] 2.3.2.1 dnsProperty has no mention of this special behaviour.
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/445c7843-e4a1-4222-8c0f-630c230a4c80
This was known as CVE-2019-14908 before being triaged back to a normal bug.
Found by Douglas Bagnall using Hongfuzz and the new fuzz_ndr_X fuzzer.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14206
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@samba.org>
Ensure that a dnsp_DnsProperty is rejected if the length data does not not
correspond to the length indicated by the union id. It was possible for
the union to be referencing memory past the end of the structure.
Found by Douglas Bagnall using Hongfuzz and the new fuzz_ndr_X fuzzer.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=14206
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This will show a leases.tdb record leak. If you SIGSTOP the smbtorture
process while it's in the 10-second wait, you will find locking.tdb
and share_entries.tdb empty after the scavenger has cleaned up. But
there will be an entry in leases.tdb left.
I have no clue how to test this properly, or how to have a reasonably
cheap assert in smbd during normal operations. The problem is that
this leak can't really be distinguished from a "normal" leak that a
crashed smbd would leave behind. Possibly we need a background job
walking leases.tdb to clean this up properly.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We only have ndrdump and the fuzzers set up for structures, not BITMAPS,
ENUMS etc.
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Tue Dec 10 17:45:46 UTC 2019 on sn-devel-184
These are not passed by pointer so the structure dump system does not work
for these. It is best to dump the containing structure instead.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This is not a security issue as it only happens when printing the structure
during debugging, not normal production.
Found by Michael Hanselmann using an NDR fuzzer and Hongfuzz.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Thanks to Douglas Bagnall for the samples, produced from seeds
generated by Samba's make test traffic, fuzzed by ndr_fuzz_X
and Hongfuzz.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Right now this panics the scavenger daemon, preventing it from doing
its work. The reopen we expect to fail with
NT_STATUS_OBJECT_NAME_NOT_FOUND thus succeeds. I know that we should
more precisely detect the scavenger crash and with Jeremy's pattern in
46899ecf836 this would be possible. However, this is C code right now,
and scanning the logfile for the panic is more I have time for right
now. The test successfully indicates failure, as the next commit will
show.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This implements two core changes:
* use NTTIME instead of struct timespec at the database layer
* use struct timespec { .tv_nsec = SAMBA_UTIME_OMIT } as special sentinel
value in smbd when processing timestamps
Using NTTIME at the database layer is only done to avoid storing the special
struct timespec sentinel values on disk. Instead, with NTTIME the sentinel value
for an "unset" timestamp is just 0 on-disk.
The NTTIME value of 0 gets translated by nt_time_to_full_timespec() to the
struct timespec sentinel value { .tv_nsec = SAMBA_UTIME_OMIT }.
The function is_omit_timespec() can be used to check this.
Beside nt_time_to_full_timespec(), there are various other new time conversion
functions with *full* in their name that can be used to safely convert between
different types with the changed sentinel value.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=7771
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Needed to support dates corresponding to (time_t)0 and (time_t)-1.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=7771
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
interpret_long_date() is now only used in the client. To enable correct
processing of dates before the UNIX epoch, call nt_time_to_full_timespec().
BUG: https://bugzilla.samba.org/show_bug.cgi?id=7771
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Add a test that shows that setting timestamps to the special
values (time_t) 4294967295, 0, -1 and anything below is broken.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=7771
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This blackbox test confirms that Samba returns NTTIME=0 when a filesystem object
has a UNIX timestamp value of 0, ie UNIX epoch start 1.1.1970.
Here's an example output from running smbstatus allinfo on such a file:
$ bin/smbclient -U slow%x //localhost/test -c "allinfo time_0_1970"
altname: T11662~T
create_time: NTTIME(0)
access_time: NTTIME(0)
write_time: NTTIME(0)
change_time: NTTIME(0)
attributes: (80)
stream: [::$DATA], 0 bytes
If you look at it with smbclient ls command, it munges the output to be 1970 so
you don't notice the problem:
$ bin/smbclient -U slow%x //localhost/test -c "ls time_0_1970"
time_0_1970 N 0 Thu Jan 1 01:00:00 1970
The test also test other time_t values -1 and 4294967295 that are used as
sentinel values in Samba code and shows that handling these values is equally
broken.
Same for time_t values < -1.
Note that I'm adding a blackbox test *and* a torture test, as with this blackbox
test I can directly control the server side, but with smbtorture I have to go
through the SMB stack to create the files which doesn't work currently.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=7771
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Otherwise we can end up with negprot.done set, but
without smbXsrv_connection_init_tables() being called.
This can cause a client self-crash.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14205
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Dec 4 21:27:24 UTC 2019 on sn-devel-184
Without this protection we will spin during decode of a string_array or nstring_array
that is terminated by only a single NUL byte, not two as required by UTF-16.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13874
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Tests to ensure that ndr_pull_string handles zero and one byte length
data correctly for both character strings and UTF-16 strings.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13874
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Fuzzing by Michael Hanselmann found an infinite loop parsing a malformed
supplemental credentials structure. There are no server-side
network-accessible calls using this code.
This patch adds an ndrdump blackbox test to replicate the issue.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13874
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Christof Schmitt <cs@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Nov 26 22:55:38 UTC 2019 on sn-devel-184
This allows ndrdump --validate to avoid following a NULL pointer when re-pushing
a valid but unusual input.
It also avoids an issue if the Samba server code were to provide a response
without an EncryptedRandomSessionKey.
At this stage ntlmssp.idl is not used for this, instead the packets are
generated with msrpc_gen().
Found by Douglas Bagnall using Hongfuzz and the new fuzz_ndr_X
fuzzer.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Nov 20 06:06:29 UTC 2019 on sn-devel-184
This demonstrates a bug found by Douglas Bagnall using Hongfuzz and the new fuzz_ndr_X
fuzzer where the value() evaluatuion could segfault if it was made to follow a NULL
pointer.
This also demonstrates that the --base64 mode works on file inputs.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
We were accidentally checking the memory just past the array instead of
checking each member.
This could have led to the size of some arrays not being checked.
Found by Michael Hanselmann using Honggfuzz and an fuzzer for Samba's
NDR layer.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13877
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Pair-programmed-with: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The PIDL bug is in the handling of arrays of arrays.
Test input provided by Michael Hanselmann and found using Hongfuzz.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13875
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Previously we would assume the array head was the talloc context
however this is not the case if the array is a fixed size inline array
within the parent struct.
In that case the overall object's talloc context is the correct
context to reference.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Pair-programmed-with: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Thu Nov 14 17:36:49 UTC 2019 on sn-devel-184
Struct members that are marked as ref pointers need to have an object
allocated for them.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Pair-programmed-with: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14191
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Pair-progammed-with: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
