Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Sep 2011 20:03:06 -0400
From: David Jones <jonesd@...umbus.rr.com>
To: john-dev@...ts.openwall.com
Cc: David Jones <jonesd@...umbus.rr.com>
Subject: Re: Patch for dynamically loaded formats


On Sep 19, 2011, at 11:58 AM, Solar Designer wrote:

> David,
> 
> I finally took a closer look at your stuff
> (john_1.7.8.jumbo6.plugin.diff and jtr_vms_2-3.zip on the wiki).

Thanks, your feedback is much appreciated.


> On Mon, Sep 05, 2011 at 11:55:04PM -0400, David Jones wrote:
>> Actually, I wasn't aware of compile-time plugins.  I did the initial work for this enhancment a couple years ago on John 1.7.3.1, and earlier this summer decided to revisit it to update it for the official 1.7.8 release, not -jumbo.  It appears the compile-time stuff assumes the module is a single source file, I have to consolidate 5 or so source files to follow that format.  The project also includes a piece that lives on OpenVMS, i.e. the uaf_to_passwd program to convert the native password hash data to a ciphertext  suitable for JtR to process.
> 
> I think this would be best integrated into -jumbo fully, not even as a
> compile-time plugin.  Then you don't need to merge any source files.
> uaf_to_passwd should probably become uaf2john, and be compiled/installed
> alongside ssh2john, etc.  If it may only be compiled on VMS natively (I
> did not verify if this is the case or not), then only refer to it from
> the proper DCL scripts.  You're not using the Makefile when building on
> VMS, right?

Yes, the Makefile only builds the vms_fmt dynamic library.  The DCL scripts are generated from the MMS description file (descip.mms, which mostly follows makefile syntax) when the zip file is built. 

I use the documented method to access the user account information (SYS$GETUAI()) and don't attempt to directly read the underlying file, SYSUAF.DAT.  SYSUAF.DAT is not a flat file and stores binary data, so getting a clean transfer to a Unix-like system can be problematic. 

> We can't afford making pthreads mandatory, but your code appears to
> support building without pthreads as well, correct?

Yes, compiling without pthread support forces the degenerate case of 0 worker threads so all work gets done by the main thread.  Processing the request list may or may be straight forward with OpenMP, I don't know that interface.

> BTW, in vms_fmt.c you set MIN_KEYS_PER_CRYPT to SINGLE_HASH_MIN.  This
> looks wrong to me: for "single crack" mode, the equivalent of this is
> ...
> 
> Also, I think you shouldn't be setting FMT_BS - you don't have a
> bitslice implementation there.

OK, I was guessing.

> 
> Regarding "FMT_CASE | FMT_8_BIT", are you only supporting a hash type
> for which this is right?  As your aaareadme.txt says, some VMS hash
> types were not case-sensitive - are you not supporting those?  I think
> it'd be best to integrate support for them as well (using Jean-loup
> Gailly's code?), but as separate formats (so that we can set the flags
> right).  What do you think?  Indeed, we can and should integrate any
> extras like this separately.

Case sensitivity and the symbol space are set on a per account basis, controlled by a flag bit (PWDMIX) in the user's SYSUAF record.  On a single system, some users can have case insensitive passwords from a limited character set while others can have mixed case with any printable character.  The format string generated in uaf_encode.c includes the state of the PWDMIX bit so the hash can be generated correctly for any password.  The hash really isn't any different, it's just whether you begin with a conversion to upper case and check for out of range characters or leave as is.

I could generate different tags based upon PWDMIX, but that would mean tracking 2 separate fmt_main structs.  In the pseudo-homedir field output by uaf_to_passwd, accounts with PWDMIX set begin with /Users while accounts with case insensitive passwords begin with /USERS.  I was thinking that would facilitate splitting up the input file for processing by different rule sets. 

>>Dave

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ