FWD: Some compilation warnings

[Luke Kenneth Casson Leighton]

hiya jerry, good to hear from you.

unrecognised opcodes are already fault-pdu'd, that's how 
ms managed to upgrade to LsaOpenPolicy3 and still
maintain backwards-compatibility.

this is likely to be related not to the info level but to
a newly-negotiated security 'blob' on the samr_get_user_info().

remember, due to my work [which andrew seem to think
is a piece of shit and not worth putting into samba,
but that's his problem.  i just wish he hadn't pissed all
over me out of jealousy, arrogance, fear, mis-management
and control-freakism in order to make himself feel better
about not having been the one to develop something better
than he _ever_ could], i discovered a security bug
in the samr_get and set _user_info methodology when
transferring user-passwords.

paul leach i believe was involved in developing a new
security mechanism that i can only presume is more secure
[let's damn well hope so, anyway] and i guess it must
have been released in SP2.

anyway, if the sam_user_get_info() or sam_user_set_info()
contains 'incorrect' info for the encryption / decryption
of the user passwords, then you are expected to return
a 'fault' pdu.

seems perfectly reasonable to me.


i presume that MS use this to detect 'ah ha!  this server
doesn't support my new spiffy-diffy more secure user-password
encryption, i'll revert to the old insecure method that
we know and love and allows an attacker to decode all
my passwords as if they were clear-text in the first place'.

so, basically, try decoding the user-password.  if it comes
out as garbage, or the length is not 516 bytes in 0x17 and
0x18 info levels, and not exactly... urrr... 16 bytes 
[each, for LM and NT] in 0x12 info level, then return a
Fault PDU.

watch out for possible differences in the rest of the
set and get, there are fields that specify whether LM
and / or NT is being supported.

these may *also* be being used, you'll have to watch / compare
network traces, as you know how, in order to find it.

btw, matty and others have decoded the samr info levels
to a better degree, now, so we now know that some of the
fields are bitfields related to password info.

luke

p.s. andrew, jeremy, when are you going to publicly apologise?

it will make life for everyone a lot easier if you do: for
a start, i won't be writing public messages that outline what
you did, any more.  it'd go a long way to repairing some of
the damage you did, and i can stop feeling like i never want
to meet either of you ever again, because i will spit in
your faces if i do.


On Wed, Jun 20, 2001 at 09:40:38AM -0500, Gerald Carter wrote:
> On Wed, 20 Jun 2001, Elrond wrote:
> 
> > The function is the stone-old "getuserinfo" (if it is set*,
> > I know, why the fault-pdu gets delivered, but unless we
> > forogt to check some return values [which is not unlikely],
> > we do so too).
> >
> > It's a known function, but with an unknown info level...
> >
> > So in our case, _samr_get_user_info() is called, with
> > infolevel 0xsomething, it doesn't know about it... how does
> > it tell the dce/rpc-rt, that it wants to respond with a
> > fault pdu? It can't... that's the part, I don't understand.
> 
> You're having the same reaction I did, Elrond.  It doesn't
> make sense, and I wouldn't have believed it unless
> I saw it with my own eyes (Jeremy didn't either) :)
> 
> 
> 
> 
> 
> 
> 
> Cheers, jerry
> ----------------------------------------------------------------------
>    /\  Gerald (Jerry) Carter                     Professional Services
>  \/    http://www.valinux.com/  VA Linux Systems   gcarter at valinux.com
>        http://www.samba.org/       SAMBA Team          jerry at samba.org
>        http://www.plainjoe.org/                     jerry at plainjoe.org
> 
>        "...a hundred billion castaways looking for a home."
>                                 - Sting "Message in a Bottle" ( 1979 )
>