Re:CM Security - introducing myself...

[Bob Aiello <cl...@optonline.net>]

Greg,

modern CM tools keep the audit log as transaction records in a
database (instead of a physical file).

Since the only interface is via the tool itself, it is pretty darned hard to
audit the history log. With enough permissions I could edit the history
log for CVS (based upon it's RCS files) and you would never know.
(The same is true if you use the Unix based sudo tool.)

I could also remove a header file and you also would never know. If
you did this with any of the other industry strength CM tools (assuming
you had gotten root) the repository would crash or at least fail it's
integrity checking utilities. You can "run" but you can't "hide". I believe
that this is the appropriate level of security for large scale financial
services
firms. I am hoping to contribute to this project by giving input on what
is an appropriate level of security for a financial services firm, based
upon
my own experience in the industry and involvement with related
industry groups (e.g. NY CitySPIN, NYECTF etc.).

Also, I am working on a discussion forum for CM tools security on
www.cmcrossroads.com . I would envite you all to join.

Bob
----- Original Message -----
From: "Greg Hudson" <gh...@MIT.EDU>
To: "Bob Aiello" <ra...@acm.org>
Cc: <de...@subversion.tigris.org>
Sent: Friday, June 20, 2003 1:13 AM
Subject: Re: introducing myself...


> You might be interested in OpenCM.  It uses signed commits and other
> cryptographic controls to ensure security properties Subversion is (so
> far) not interested in.  Though I'm not sure that's the approach you
> want to take.
>
> On Wed, 2003-06-18 at 23:50, Bob Aiello wrote:
> > (e.g. database
> > security & integrity checking, audit logs that cannot be
> > found - let along tampered with).
>
> The normal approach I know about for ensuring the integrity of audit
> logs is to send them over the network to another machine.  I'm kind of
> curious how else you would propose to make it impossible to find and
> tamper with audit logs.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Re:CM Security - introducing myself...

[Daniel Berlin <db...@dberlin.org>]

On Fri, 20 Jun 2003, Greg Hudson wrote:

> On Thu, 2003-06-19 at 07:42, Bob Aiello wrote:
> > modern CM tools keep the audit log as transaction records in a
> > database (instead of a physical file).
> >
> > Since the only interface is via the tool itself, it is pretty darned hard to
> > audit the history log.
>
> That's all?  Because the file format isn't plain ASCII, you think it's
> more secure?
>
> It only takes one mildly clueful hacker about half an hour (or a little
> more time, if they don't have a copy of the DB software to hack on) to
> write a script to modify the audit log or remove data from the
> repository, and then every two-bit script kiddie can do the same.  The
> community that can developer buffer overflow attacks is not going to be
> stymied by a well-documented binary file format, or even an undocumented
> one.

Just to make this clear: A few years ago, in the space of 3 weeks in
between classes, I reverse engineered Microsoft's PDB codeview format (it
pretends to be documented but they  consider it internal so they don't
give anywhere near the necessary info to do something useful with it), as
well as their entire C++ name mangling scheme, and extended GDB to be able
to handle both.

I was just bored during that time, too. It's not like anyone was paying
me.
Entire communities have grown up around modifying undocumented data files
and formats for various games.  Heck, my brother, not even close to a
programmer, used to sit with a hex editor and figure out how to hack the
save files for whatever game he was playing at the moment.

This was before one had tools besides a good hex editor that you could use
on binary files, like scripting languages supporting unpack operations,
etc.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Re:CM Security - introducing myself...

[Greg Hudson <gh...@MIT.EDU>]

On Thu, 2003-06-19 at 07:42, Bob Aiello wrote:
> modern CM tools keep the audit log as transaction records in a
> database (instead of a physical file).
> 
> Since the only interface is via the tool itself, it is pretty darned hard to
> audit the history log.

That's all?  Because the file format isn't plain ASCII, you think it's
more secure?

It only takes one mildly clueful hacker about half an hour (or a little
more time, if they don't have a copy of the DB software to hack on) to
write a script to modify the audit log or remove data from the
repository, and then every two-bit script kiddie can do the same.  The
community that can developer buffer overflow attacks is not going to be
stymied by a well-documented binary file format, or even an undocumented
one.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: CM Security - introducing myself...

["Martin v. Löwis" <ma...@v.loewis.de>]

Bob Aiello <cl...@optonline.net> writes:

> modern CM tools keep the audit log as transaction records in a
> database (instead of a physical file).
> 
> Since the only interface is via the tool itself, it is pretty darned hard to
> audit the history log. 

This is a very strange view of the world. Merely using a database
instead of flat files does not change the security *at all*.

> With enough permissions I could edit the history
> log for CVS (based upon it's RCS files) and you would never know.
> (The same is true if you use the Unix based sudo tool.)

With enough permissions I could edit your Oracle or DB2 database file,
on disk. I don't need to go through the Oracle library - instead, I
can just edit the files that Oracly writes (if I have the permission).

> I could also remove a header file and you also would never know. If
> you did this with any of the other industry strength CM tools (assuming
> you had gotten root) the repository would crash or at least fail it's
> integrity checking utilities. 

Again, this assumes I have access to the files on the disk. With
access to the files, I can trick any other industry-strength into
believing the header file was never there.

> You can "run" but you can't "hide". I believe that this is the
> appropriate level of security for large scale financial services
> firms.

I think you are grossly mistaken in your conclusion. You can "hide"
with any other CM system just as well if you can overcome OS
limitations. Heck, I could replace the CM software *itself*.

Regards,
Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org