Re: Fwd: Fwd: question regarding verification of a debian installation iso
Eduardo M KALINOWSKI writes: > How much do you trust your USB drive? It could have a malicious > controller that detects when the correct Fedora files are written to > it, and replaces with hacked copies. And when you try to verify the > copy, it detects this and returns the SHA1 (or any other checksum) of > the original files. How would the USB drive tell whether you were reading the file to verify its checksum or to use its contents? -- Ben Pfaff http://benpfaff.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hem0xki@benpfaff.org
Re: Security Debian Questions
"Abdul bijur Vallarkodath" <[EMAIL PROTECTED]> writes: > Please do not mis interpret this, but I think you guys are posting on the > wrong mailing list. Please take you doubts to #debian or some debian help > mailing list. I think you are confusing debian-security with debian-security-announce. The former is for "Discussion about security issues, including cryptographic issues, that are of interest to all parts of the Debian community." The latter is where "The security team informs the users about security problems by posting security advisories about Debian packages on this list." -- Ben Pfaff http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
martin f krafft <[EMAIL PROTECTED]> writes: > However, doesn't CBC or EBC make sure that every block is > chained to its predecessor, making even the very last block of > a file dependent on the bits of the very first block? Yes and no. If you change the first block in a set of CBC-chained blocks, the last block will change. But to recover the contents of the last block, you only need the last block and the preceding block (and the key). -- "I was born lazy. I am no lazier now than I was forty years ago, but that is because I reached the limit forty years ago. You can't go beyond possibility." --Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Access on Port 0
Wade Richards <[EMAIL PROTECTED]> writes: > Notice the "PROTO=UDP" part of the message. It means that this > is a UDP packet, not a TCP packet. UDP is not a socket-based > protocol, so the port number is meaningless for UDP packets. This statement is nonsense. Both TCP and UDP have 16-bit port numbers and both use the sockets API. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Access on Port 0
Wade Richards <[EMAIL PROTECTED]> writes: > Notice the "PROTO=UDP" part of the message. It means that this > is a UDP packet, not a TCP packet. UDP is not a socket-based > protocol, so the port number is meaningless for UDP packets. This statement is nonsense. Both TCP and UDP have 16-bit port numbers and both use the sockets API.
enscript -e option a security risk?
In looking through the print filter generated by magicfilter, I noticed that it gives the -e option to GNU enscript. The -e option turns on special "escapes", including the following as documented in the enscript manpage: epsfinline EPS file to the document. Escape's syntax is: [EMAIL PROTECTED] where options is an optional sequence of option characters and values enclosed with brackets and filename is the name of the EPS file. If filename ends to the `|' character, then file- name is assumed to name a command that prints EPS data to its standard output. In this case, enscript opens a pipe to the specified command and reads EPS data from pipe. It seems to me that this is a security risk. Agreed? If so, I'll file a bug against magicfilter asking that this option be removed from the filters. This option is present in several filters, by the way: pfaffben:/etc/magicfilter# grep -l 'enscript.*-e' * bj600-filter bj600_draft-filter bj610-filter bj800-filter bj800_draft-filter cpsonly300-filter cpsonly400-filter cpsonly600-filter psonly300-filter psonly400-filter pfaffben:/etc/magicfilter# -- "A computer is a state machine. Threads are for people who cant [sic] program state machines." --Alan Cox
enscript -e option a security risk?
In looking through the print filter generated by magicfilter, I noticed that it gives the -e option to GNU enscript. The -e option turns on special "escapes", including the following as documented in the enscript manpage: epsfinline EPS file to the document. Escape's syntax is: ^@epsf[options]{filename} where options is an optional sequence of option characters and values enclosed with brackets and filename is the name of the EPS file. If filename ends to the `|' character, then file- name is assumed to name a command that prints EPS data to its standard output. In this case, enscript opens a pipe to the specified command and reads EPS data from pipe. It seems to me that this is a security risk. Agreed? If so, I'll file a bug against magicfilter asking that this option be removed from the filters. This option is present in several filters, by the way: pfaffben:/etc/magicfilter# grep -l 'enscript.*-e' * bj600-filter bj600_draft-filter bj610-filter bj800-filter bj800_draft-filter cpsonly300-filter cpsonly400-filter cpsonly600-filter psonly300-filter psonly400-filter pfaffben:/etc/magicfilter# -- "A computer is a state machine. Threads are for people who cant [sic] program state machines." --Alan Cox -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is ident secure?
"Layne" <[EMAIL PROTECTED]> writes: > OK they just keep coming. I had 8 messages at 11:00PM , all of who I knew. > Now I have 227 in my in box of solicitors all of who I didn't subscribe to. > And you wonder why I get mad. Did it ever occur to you that maybe it's not acceptable to harass everyone on the mailing list just because someone subscribed you? Try to act a little more mature and follow the unsubscribe instructions like a normal person would. The only way to subscribe in the first place is by replying to a confirmation message, so you (or someone who has access to your account; has your account security been compromised?) must have subscribed.
Re: Is ident secure?
"Layne" <[EMAIL PROTECTED]> writes: > OK they just keep coming. I had 8 messages at 11:00PM , all of who I knew. > Now I have 227 in my in box of solicitors all of who I didn't subscribe to. > And you wonder why I get mad. Did it ever occur to you that maybe it's not acceptable to harass everyone on the mailing list just because someone subscribed you? Try to act a little more mature and follow the unsubscribe instructions like a normal person would. The only way to subscribe in the first place is by replying to a confirmation message, so you (or someone who has access to your account; has your account security been compromised?) must have subscribed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Layne (was: Re: Is ident secure?)
Paul Visscher <[EMAIL PROTECTED]> writes: > Ed Street [EMAIL PROTECTED] said: > > Already sent mail to the list admin on the bottom of each email. > > I just submitted his address in at > http://www.debian.org/MailingLists/unsubscribe to be unsubscribed, > hopefully that will work... I just submitted his address to [EMAIL PROTECTED], hopefully they'll LART him.
Re: Layne (was: Re: Is ident secure?)
Paul Visscher <[EMAIL PROTECTED]> writes: > Ed Street [[EMAIL PROTECTED]] said: > > Already sent mail to the list admin on the bottom of each email. > > I just submitted his address in at > http://www.debian.org/MailingLists/unsubscribe to be unsubscribed, > hopefully that will work... I just submitted his address to [EMAIL PROTECTED], hopefully they'll LART him. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X & tcp listening
Jim Breton <[EMAIL PROTECTED]> writes: > On Mon, May 28, 2001 at 01:46:07PM +0200, Tomasz Olszewski wrote: > > If an user > > creates his own $HOME/.xserverrc, it overrides the system wide > > xserverrc. > > So make /usr/bin/X11/X a wrapper for the "real" X. > > Problem with this is, if you upgrade or re-install the package > containing it, it will get replaced by the package's copy and you > will have to do this again. dpkg-divert is your friend. -- "MONO - Monochrome Emulation This field is used to store your favorite bit." --FreeVGA Attribute Controller Reference
Re: X & tcp listening
Jim Breton <[EMAIL PROTECTED]> writes: > On Mon, May 28, 2001 at 01:46:07PM +0200, Tomasz Olszewski wrote: > > If an user > > creates his own $HOME/.xserverrc, it overrides the system wide > > xserverrc. > > So make /usr/bin/X11/X a wrapper for the "real" X. > > Problem with this is, if you upgrade or re-install the package > containing it, it will get replaced by the package's copy and you > will have to do this again. dpkg-divert is your friend. -- "MONO - Monochrome Emulation This field is used to store your favorite bit." --FreeVGA Attribute Controller Reference -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: funny rpc.statd events
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > This was fixed a month or two before potato was released. I've seen those too, on up-to-date woody, so I don't think it really got fixed. > On Tue, Oct 10, 2000 at 09:09:52PM -0500, Herbert Ho wrote: > > hi guys. i have logcheck installed so i got this message tonight: > >=20 > > (sorry about the long lines, its the way it came to me) > >=20 > > Unusual System Events > > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > > Oct 10 19:31:37 thosolin=20 > > Oct 10 19:31:37 thosolin /sbin/rpc.statd[125]: gethostbyname error for ^X= > =F7=FF=BF^X=F7=FF=BF^Y=F7=FF=BF^Y=F7=FF=BF^Z=F7=FF=BF^Z=F7=FF=BF^[=F7=FF=BF= > ^[=F7=FF=BF%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\2= > 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\= > 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220= > \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22= > 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2= > 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\= > 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220= > \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22= > 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2= > 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\= > 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220= > \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2!
Re: funny rpc.statd events
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > This was fixed a month or two before potato was released. I've seen those too, on up-to-date woody, so I don't think it really got fixed. > On Tue, Oct 10, 2000 at 09:09:52PM -0500, Herbert Ho wrote: > > hi guys. i have logcheck installed so i got this message tonight: > >=20 > > (sorry about the long lines, its the way it came to me) > >=20 > > Unusual System Events > > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > > Oct 10 19:31:37 thosolin=20 > > Oct 10 19:31:37 thosolin /sbin/rpc.statd[125]: gethostbyname error for ^X= > =F7=FF=BF^X=F7=FF=BF^Y=F7=FF=BF^Y=F7=FF=BF^Z=F7=FF=BF^Z=F7=FF=BF^[=F7=FF=BF= > ^[=F7=FF=BF%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\2= > 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\= > 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220= > \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22= > 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2= > 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\= > 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220= > \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22= > 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2= > 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\= > 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220= > \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]