| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> heh
<1> well
<0> basically.. a db that can be added to
<1> how would i prove it
<0> but not updated
<0> is needed.
<1> create a hash of each message, and stick the hash in a database ?
<0> and for every change
<1> that sort of thing ?
<0> it needs to be documented
<0> as a revision, or as a new document at the very least
<0> yah
<0> then backup the database daily
<1> gotcha
<0> etcetc
<1> sure
<0> to a readonly medium
<1> well i havnet been asked to implement that, just to work out this offsite compliance thing
<0> there are companies that are paid lots of cash for just simple storage solutions with proof
<0> (offsite)
<1> yeah
<1> CA has this beast of a product
<0> they all proxy mail though
<0> mail goes to them, they send it to you
<1> im sure they do
<0> once it's been archived.
<0> they hafta be first point of contact, otherwise it cant be proven
<0> heh
<1> CA you can install it on a box-in-the-middle
<0> these databases hafta be accessible to audit
<0> at any time as well
<0> its kinda crazy
<1> nod
<1> im not interested, to be honest with you
<0> Sarbanes and Oxley wrote that compliancy paper without much technical thought
<0> *shrug*
<0> !find aic
<2> Found 4 key(s): aicisanewb aichains package exchange
<0> !aicisanewb
<2> <aic> wtf is this <aic> from <#@[]> <aic> nice from address, bro <-- lewl, newb.
<0> ;P
<1> your mom
<0> hah
<1> HEHE
<0> <aic> wtf is dotqmail
<0> ?
<0> heh
<0> !find crazy
<2> Found 1 key(s): crazy
<1> lol fabrications!
<0> !crazy
<2> <gnak> anyone using dspam with vpopmail? <gnak> what is qmail <0> he has vpopmail, but doesnt know qmail? <gnak> vpopmail? <gnak> dude why am i even in this channel
<3> Volatile: please see the email i just sent to the vpopmail list
<0> uh
<0> firstly, the 0666 doesnt matter since it's all atomic operations
<0> on the tmp file
<0> not to mention regular users dont have acs to create files in /var/qmail/users
<0> not sure why the ***ign file is opened r/w.. but it probably doesnt matter since there's a tmp file used to build it.
<3> Volatile: right but since it's opened 0666, if someone were to guess the filename, they could write to it while it is open
<3> i'm not sayign it's some like
<3> insanely urgent vulnerability
<3> it would be practically impossible to exploit it
<0> no
<0> they couldnt
<3> why not?
<3> it's writeable, they could write to it
<3> ***uming permissions above the file permit
<0> the contents are updated at close()
<3> but the file is opened world readable
<0> since the file is moved over ***ign
<3> err writable
<0> and the permissions changed
<0> and then closed
<0> it should not be an issue.
<0> if the perms arent changed and then closed
<3> couldn't they open it up while you're working on it, write some data
<0> then there may be a race condition
<0> no
<0> thats not how file operations work
<3> so the file doesn't even exist until close() is called?
<0> no
<0> *sigh*
<0> if i open a file
<0> and you open that same file
<0> the contents of that file will not change to either of our descriptors from eachother
<0> only the changes we make will be available
<0> the last person to close()
<0> will have the final say
<0> unless some of our changes dont overlap
<0> and even in some cases
<0> that wont matter.
<0> read about kernels and fs interaction
<0> there may possible be a race condition
<3> so you're saying if i open a file nd write 300MB, that nobody can thoss anything in the middle while i'm writing?
<0> possibly
<0> in the middle?
<0> okay
<0> lets say i open foo.1
<3> or in the beginning, or whtaever
<0> with 0666
<3> k.
<0> you now have perms to write to that file
<0> so you open it
<0> in the meantime, ive written 5 bytes 'xxxxx'
<0> but have not closed the file
<0> you now write 'aaa'
<0> and then close the file
<0> the file will read to everyone else 'aaa'
<0> i close the file
<0> 'xxxxx'
<0> thats a very simplified version of events
<3> ok
<0> theres many things involved
<0> how often the working area is synced to the fs
<0> how much data is being written
<0> but what it comes down to
<0> is a race condition
<0> in this case with ***ign
<0> IF, the perm change isnt made
<0> before the rename and close.
<3> so during a short period of time, the file reads to everyone else the content that I want it to
<0> and also OS to OS
<0> in theory, it could
<3> also, what happens if you open the file, i open the file, you write your ****, change perms, and close, then i write my **** and close
<0> someone would need to re-compile the cdb
<0> i do not believe the sync will take place
<0> but im not sure how deep permissions checking goes
<3> ok
<0> in that area.
<0> its worth a test.
<3> so it may or may not be exploitable
<0> write something and figure it out
<0> if it is
<3> but you do agree that it should be changed
<0> it may be a per-OS basis too
<0> dude
<0> i have no idea why ANY file would be being opened 0666
<3> heh
<3> kk
<0> i also have NO idea why temporary file creation is being done insecurely
<0> (ie: not using the standard mkstemp call)
<3> actually, if the condition was expoitable it wouldn't be all that difficult to exploit it
<3> just have something trying to open files in a loop in that directory as writable, and keep doing it until it hits
<0> oh man
<0> they called open() without p***ing the perms
<3> still a very very very low risk issue
<0> thats why it opened with 0666
<0> he's running an older vpopmail too
<0> newer vpopmail opens it WRONLY
<0> so it was just lazy coding
<3> imagine that ;)
Return to
#qmail
or
Go to some related
logs:
#stocks
#computers
#nhl
homemade alcohol beginners
#computers
#beginner
delphi UpdateLayeredWindow
#gentoo
#beginner
#politics
|
|