On Sunday 30 April 2006 10:29, James Harper wrote:
> > Hello,
> >
> > On Sunday 30 April 2006 08:16, James Harper wrote:
> > > The bin_to_base64 routine appears to be pretty broken, or at least
> > > incompatible with the base64 specification.
> >
> > Yes, it is incompatible with the base64 RFC. I wrote the code before I
>
> was
>
> > aware that there was a base64 binary specification.
>
> I had the same issue once with a LUHNS checksum algorithm that I
> embedded in a crystal report. The initial version had a bug for certain
> values and now the buggy version seems to have been copied everywhere :)
>
> > Yes agreed, except that I would say that it "modifies" rather than
>
> "mucks
>
> > up" the subsequent digits.
>
> See below.
>
> > > Secondly, there is some problem with the way the last digit is
>
> handled,
>
> > > but I'm not sure what.
> >
> > The last digit is not shifted as are other digits so the result is
>
> right
>
> > justified instead of left justified.
>
> I just sort of figured that out, but am glad you verified it.
>
> > > Obviously it's
> > > compatible with itself at the moment, but there may be security
> > > implications, I think the bug results in a potentially large
>
> reduction
>
> > > in hash space.
> >
> > I am really skeptical about the above remark, but it is possible. If
>
> it
>
> > is true, I would give this problem a much higher probability.
>
> I just threw together a to_base64 routine (in C#), and in order to make
> it compatible with the bacula version, I did the following:
>
> For byte 0 to byte 15:
> If byte index % 3 = 1 and bit 7 is set then set bits 0 and 1 in the
> previous byte
> If byte index % 3 = 2 and bit 7 is set then set bits 0, 1, 2, and 3 in
> the previous byte
>
> For each Base64 digit value (before printing)
> If we are looking at the last Base64 'digit', shift it right by 4 bits.
>
> This says to me that worst case (eg the necessary bytes in the hash have
> the high bits set), 32 bits will always be set to 1, effectively
> reducing the hash space from 128 down to 96 bits. I'm not sure if this
> is significant though.
>
> > > Also, anyone trying to authenticate to bacula from
> > > 'outside' the bacula code base (eg me :) is going to run into
>
> problems.
>
> > Yes, I consider this a security "feature" it means that 14 year old
> > kiddies
> > using a Perl script will not be able to access Bacula without doing
>
> some
>
> > real
> > programming. Obviously this won't be an obsticle to anyone serious
>
> about
>
> > attacking Bacula.
>
> Agreed.
>
> > Well, the code to "correct" the encoding is already in version 1.39 in
>
> the
>
> > current CVS. You can check for yourself what is needed to completely
>
> fix
>
> > it
> > (more than your fix above, but not much).
>
> I'll have a look. Thanks.
>
> > The real issue here is that if we change this algorithm, it will make
>
> all
>
> > authentication incompatible with the prior algorithm. This could be a
> > major
> > problem for users that have 50 or 60 Bacula clients. For them it is
> > virtually impossible to upgrade simultaneously.
> >
> > If this is something that you consider important, then the way to
>
> ensure
>
> > that
> > it gets implemented in Bacula is to upgrade the current authentication
> > handshake in a compatible way so that (at least for some time) Bacula
>
> can
>
> > run both algorithms
>
> I've thought about this and can't think how the old behaviour could be
> detected reliably. There are a small number of hashes where yours and
> the rfc base64 algorithms will produce the same result, so we can't just
> do 'the new base64 didn't give us the right result so we'll use the
> old'.
No, that would not work very well. The solution, which you seem to imply
below is simply to send a different initial Hello "signon" that contains all
the necessary information, plus the ability to extend it to different hashes
in the future. The new handshake can be easily distinguished from the old.
>
> In the future, it would be good if a protocol version could be
> negotiated so that (to a point) a new director could talk to a downlevel
> storage or file daemon in a bug for bug compatible way. Maybe this could
> be a way around the above?
>
> Thanks
>
> James
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
