[Full-disclosure] Vulnerability discloses PIN used in Microsoft Excel secure printing
Thor (Hammer of God)
thor at hammerofgod.com
Mon Jan 31 18:15:14 GMT 2011
I assume it is embedded so that cancelled or queued jobs can still require PIN. You can't have one job pause all other jobs in the queue, so it would need some way of continuing from bypass. The whole "vulnerability" angle is pretty lame.
>From: full-disclosure-bounces at lists.grok.org.uk [mailto:full-disclosure-
>bounces at lists.grok.org.uk] On Behalf Of Michael Holstein
>Sent: Monday, January 31, 2011 8:34 AM
>To: Christian Sciberras
>Cc: full-disclosure at lists.grok.org.uk
>Subject: Re: [Full-disclosure] Vulnerability discloses PIN used in Microsoft
>Excel secure printing
>>> Wtf, I've never heard heard of a 'secure' print :S
>Most large multifunction devices do this .. it's not "secure" in the
>traditional (crypto) sense of the word, it's just a part of the job sent via
>the postscript driver. Look at the PSD files for any large multifunction and
>you'll find the options for it.
>How it works is instead of printing the job immediately, it queues and holds
>until the operator goes and enters the code on the console .. so that you have
>time to walk over to the printer and grab it, versus having it sit there while
>you walk down the hall.
>What's interesting is that Excel is embedding the PIN (part of the printer
>driver) in the default printer settings it saves in the document metadata.
>The PIN itself isn't particularly private (it's sent in the clear when
>printing) but embedding it is dumb.
>Cleveland State University
>Full-Disclosure - We believe in it.
>Hosted and sponsored by Secunia - http://secunia.com/
Full-Disclosure is hosted and sponsored by Secunia.