Bug#911844: okular: Prints to the wrong printer

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Brian Potkin-2
Severity: critical
thanks



On Thu 25 Oct 2018 at 12:50:25 +0100, Brian Potkin wrote:

> Package: okular
> Version: 4:17.12.2-2
> Severity: critical
> Tags: upstream security
>
>
>
> "critical" because a document should always go to where it is sent.
> Please reduce the severity if I have overestimated the security
> implications.
>
> The CUPS version being used is 2.2.8-5 and cups-browsed is not running.
> The issue was encountered while taking another look at #911702.
>
>  brian@test:~$ lpstat -e
>  aaa
>  realq_desktop
>  test
>
> aaa and test are local queues set up with
>
>  lpadmin -p <destination> -v file:/home/brian/capture -E -m drv:///sample.drv/generic.ppd
>
> and realq_desktop is a queue on a remote machine.
>
> Okular was started from a terminal. Printing to realq_desktop produces an
> output of
>
>  request id is aaa-41 (1 file(s))
>
> The job is always sent to a local queue when its destination precedes
> realq_desktop alphabetically.
>
> Removing the aaa queue gets
>
>  /usr/bin/lp: No such file of directory (which is #911702)
>
> I believe printing from LibreOffice to be based on the same principles
> as printing from Okular. Printing from that application is not an issue.
> qpdfview is another affected application.

I have retested this. There is no change on the present unstable. I
cannot see why a confidential print job going to a staff printer is
anything but a security issue. Maybe this is something that merits
the tag of normal but explanations are in short supply.

Regards,

Brian.

Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Lisandro Damián Nicanor Pérez Meyer-2


Hi Brian!


El lun., 10 jun. 2019 16:54, Brian Potkin <[hidden email]> escribió:
Severity: critical
thanks



On Thu 25 Oct 2018 at 12:50:25 +0100, Brian Potkin wrote:

> Package: okular
> Version: 4:17.12.2-2
> Severity: critical
> Tags: upstream security
>
>
>
> "critical" because a document should always go to where it is sent.
> Please reduce the severity if I have overestimated the security
> implications.

Please feel free to prove me wrong.

As far as I understand printing sometimes means an unencrypted connection to a printer, which means a man in the middle attack should be easy to achieve. Thus whenever you are printing you should already trust the network and whatever is in it.

Exception is probably a printer managed directly by CUPS.
Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Martin Steigerwald
In reply to this post by Brian Potkin-2
severity: important
thanks

Hi Brian,

Brian Potkin - 10.06.19, 21:32:

> Severity: critical
> thanks
>
> On Thu 25 Oct 2018 at 12:50:25 +0100, Brian Potkin wrote:
> > Package: okular
> > Version: 4:17.12.2-2
> > Severity: critical
> > Tags: upstream security
> >
> >
> >
> > "critical" because a document should always go to where it is sent.
> > Please reduce the severity if I have overestimated the security
> > implications.
> >
> > The CUPS version being used is 2.2.8-5 and cups-browsed is not
> > running. The issue was encountered while taking another look at
> > #911702.>
[…]
> > The job is always sent to a local queue when its destination
> > precedes
> > realq_desktop alphabetically.
[…]
> I have retested this. There is no change on the present unstable. I
> cannot see why a confidential print job going to a staff printer is
> anything but a security issue. Maybe this is something that merits
> the tag of normal but explanations are in short supply.

Brian, before raising a bug severity to the highest severity possible,
please read and understand the Debian's release team guidelines
regarding release critical bugs¹ as well as the general descriptions of
bug severities².

A "critical" bug is a bug that introduces a (remotely exploitable)
security hole on systems you install the package to. A "grave" bug is a
bug that introduces a (remotely exploitable) security hole allowing
access to the accounts of users using the package.

None of this is the case here.

If at all, the bug might be "serious" if in the maintainers opinion it
would make the package unsuitable for release.

Now please respect the reduced bug severity. Raising the severity again
won't get you any priority handling with an already understaffed Debian
Qt/KDE team. This is a community of people who are mostly doing unpaid
work.


Two ways to use your (and our) time in a more productive manner are:

1) Retest with Okular 18.04 from Debian experimental (in case you run
buster/sid). Or start KDE Neon in a machine and try with the newest
Okular available there.

2) Remind upstream in a friendly way to have a look at the issue. Once
there is a patch upstream it is very likely it could be backported for
buster. Maybe it would be an idea to raise the upstream bug to KDE's
security team.


[1] https://release.debian.org/testing/rc_policy.txt

[2] https://www.debian.org/Bugs/Developer

Thanks,
--
Martin

Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Brian Potkin-2
On Tue 11 Jun 2019 at 09:53:50 +0200, Martin Steigerwald wrote:

> severity: important
> thanks
>
> Hi Brian,
>
> Brian Potkin - 10.06.19, 21:32:
> > Severity: critical
> > thanks
> >
> > On Thu 25 Oct 2018 at 12:50:25 +0100, Brian Potkin wrote:
> > > Package: okular
> > > Version: 4:17.12.2-2
> > > Severity: critical
> > > Tags: upstream security
> > >
> > >
> > >
> > > "critical" because a document should always go to where it is sent.
> > > Please reduce the severity if I have overestimated the security
> > > implications.
> > >
> > > The CUPS version being used is 2.2.8-5 and cups-browsed is not
> > > running. The issue was encountered while taking another look at
> > > #911702.>
> […]
> > > The job is always sent to a local queue when its destination
> > > precedes
> > > realq_desktop alphabetically.
> […]
> > I have retested this. There is no change on the present unstable. I
> > cannot see why a confidential print job going to a staff printer is
> > anything but a security issue. Maybe this is something that merits
> > the tag of normal but explanations are in short supply.
>
> Brian, before raising a bug severity to the highest severity possible,
> please read and understand the Debian's release team guidelines
> regarding release critical bugs¹ as well as the general descriptions of
> bug severities².
>
> A "critical" bug is a bug that introduces a (remotely exploitable)
> security hole on systems you install the package to. A "grave" bug is a
> bug that introduces a (remotely exploitable) security hole allowing
> access to the accounts of users using the package.

Thank you, Martin, for taking the time and trouble to explain. I admit
to feeling uneasy about raising the severity level and did give it some
thought - but obviously not enough. Anyway, something it's for me to
take into account for the future.

> None of this is the case here.
>
> If at all, the bug might be "serious" if in the maintainers opinion it
> would make the package unsuitable for release.
>
> Now please respect the reduced bug severity. Raising the severity again
> won't get you any priority handling with an already understaffed Debian
> Qt/KDE team. This is a community of people who are mostly doing unpaid
> work.
 
I have no intention of touching the severity level again.

> Two ways to use your (and our) time in a more productive manner are:
>
> 1) Retest with Okular 18.04 from Debian experimental (in case you run
> buster/sid). Or start KDE Neon in a machine and try with the newest
> Okular available there.

There might be time for me to do both of these today or tomorrow.
 
> 2) Remind upstream in a friendly way to have a look at the issue. Once
> there is a patch upstream it is very likely it could be backported for
> buster. Maybe it would be an idea to raise the upstream bug to KDE's
> security team.

You seem to have done that. Thanks.

Regards,

Brian.

Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Martin Steigerwald
Brian Potkin - 11.06.19, 10:42:
> On Tue 11 Jun 2019 at 09:53:50 +0200, Martin Steigerwald wrote:
[…]
> > Two ways to use your (and our) time in a more productive manner are:
> >
> > 1) Retest with Okular 18.04 from Debian experimental (in case you
> > run
> > buster/sid). Or start KDE Neon in a machine and try with the newest
> > Okular available there.
>
> There might be time for me to do both of these today or tomorrow.

Wonderful.

> > 2) Remind upstream in a friendly way to have a look at the issue.
> > Once there is a patch upstream it is very likely it could be
> > backported for buster. Maybe it would be an idea to raise the
> > upstream bug to KDE's security team.
>
> You seem to have done that. Thanks.

Yes, appeared to be the quickest way to more this forward for me.

There is a reply by Albert already. He is member of KDE security team
and AFAIK also develops on Okular. Please review his comments there and
answer accordingly. It appears he does not yet understand on how to
reproduce. Maybe, if you can, give a concrete example with the necessary
CUPS commands or probably an example configuration file.

Thank you very much.

Best,

Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Brian Potkin-2
On Tue 11 Jun 2019 at 13:20:40 +0200, Martin Steigerwald wrote:

> Brian Potkin - 11.06.19, 10:42:
> > On Tue 11 Jun 2019 at 09:53:50 +0200, Martin Steigerwald wrote:
> […]
> > > Two ways to use your (and our) time in a more productive manner are:
> > >
> > > 1) Retest with Okular 18.04 from Debian experimental (in case you
> > > run
> > > buster/sid). Or start KDE Neon in a machine and try with the newest
> > > Okular available there.
> >
> > There might be time for me to do both of these today or tomorrow.
>
> Wonderful.

And good fun.

I used the neon-user-20190606-1138.iso (okular 19.04.1). Everything
behaved normally. No observed bug there. Okular 18.04 from experimental
wouldn't install because of unmet depenencies. Another time, perhaps.

> > > 2) Remind upstream in a friendly way to have a look at the issue.
> > > Once there is a patch upstream it is very likely it could be
> > > backported for buster. Maybe it would be an idea to raise the
> > > upstream bug to KDE's security team.
> >
> > You seem to have done that. Thanks.
>
> Yes, appeared to be the quickest way to more this forward for me.
>
> There is a reply by Albert already. He is member of KDE security team
> and AFAIK also develops on Okular. Please review his comments there and
> answer accordingly. It appears he does not yet understand on how to
> reproduce. Maybe, if you can, give a concrete example with the necessary
> CUPS commands or probably an example configuration file.

I will reply to the upstream bug report later.

The various contributions to this report are appreciated. I have learnt
a thing or two.

Regards,

Brian.

Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Martin Steigerwald
Hi Brian.

Brian Potkin - 11.06.19, 21:13:

> On Tue 11 Jun 2019 at 13:20:40 +0200, Martin Steigerwald wrote:
> > Brian Potkin - 11.06.19, 10:42:
> > > On Tue 11 Jun 2019 at 09:53:50 +0200, Martin Steigerwald wrote:
> > […]
> >
> > > > Two ways to use your (and our) time in a more productive manner
> > > > are:
> > > >
> > > > 1) Retest with Okular 18.04 from Debian experimental (in case
> > > > you
> > > > run
> > > > buster/sid). Or start KDE Neon in a machine and try with the
> > > > newest
> > > > Okular available there.
> > >
> > > There might be time for me to do both of these today or tomorrow.
> >
> > Wonderful.
>
> And good fun.

Thank you for your contribution.

> I used the neon-user-20190606-1138.iso (okular 19.04.1). Everything
> behaved normally. No observed bug there. Okular 18.04 from
> experimental wouldn't install because of unmet depenencies. Another
> time, perhaps.

Hmmm, so it works okay with okular 19.04.1.

That means somewhere between 17.12 and 19.04.1 is a bug fix for the issue
you reported. Maybe upstream has an idea which one it might be. At this
point I believe all that could be done would be to find and then backport
that fix, as Debian is in deep freeze and packaging 19.04 thus out of
scope.

Thanks,
--
Martin

Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Martin Steigerwald
Martin Steigerwald - 11.06.19, 23:37:

> > I used the neon-user-20190606-1138.iso (okular 19.04.1). Everything
> > behaved normally. No observed bug there. Okular 18.04 from
> > experimental wouldn't install because of unmet depenencies. Another
> > time, perhaps.
>
> Hmmm, so it works okay with okular 19.04.1.
>
> That means somewhere between 17.12 and 19.04.1 is a bug fix for the
> issue you reported. Maybe upstream has an idea which one it might be.
> At this point I believe all that could be done would be to find and
> then backport that fix, as Debian is in deep freeze and packaging
> 19.04 thus out of scope.

Well it would be helpful to test with versions in between.

So in case you are still having fun with that, Brian, that would be
something you could do :). One way might be to test with Ubuntu live
systems of different versions. Another way would be to build the thing
yourself and do a git bisect. But well maybe upstream has an idea.

--
Martin

Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Michael Weghorn
In reply to this post by Martin Steigerwald
Hi,

On 11/06/2019 23.37, Martin Steigerwald wrote:
> Hmmm, so it works okay with okular 19.04.1.
>
> That means somewhere between 17.12 and 19.04.1 is a bug fix for the issue
> you reported. Maybe upstream has an idea which one it might be. At this
> point I believe all that could be done would be to find and then backport
> that fix, as Debian is in deep freeze and packaging 19.04 thus out of
> scope.

I've investigated a bit and it's not an Okular issue, but one in the Qt
print dialog with printers that don't have PPD files. It can be
reproduced e.g. with kate just the same and Brian even mentioned in the
initial report that qpdfview is affected as well.

The issue has been fixed upstream (qtbase) with the following commit (so
that's what would have to be backported):


    commit 84cc8d0badb4abc3c9a96d59c61dddce916a216c
    Author: Albert Astals Cid <[hidden email]>
    Date:   Mon Feb 5 09:20:20 2018 +0100

        cups: Support raw printers

        They don't have a ppd but we don't *really* need a ppd to just
        print

        Change-Id: Idf6b6dafc19420a511b057194488e2170cae4d70


This probably also fixes #911702, but I didn't test that explicitly.


Regards,
  Michael


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Martin Steigerwald
Michael Weghorn - 15.06.19, 23:52:

> On 11/06/2019 23.37, Martin Steigerwald wrote:
> > Hmmm, so it works okay with okular 19.04.1.
> >
> > That means somewhere between 17.12 and 19.04.1 is a bug fix for the
> > issue you reported. Maybe upstream has an idea which one it might
> > be. At this point I believe all that could be done would be to find
> > and then backport that fix, as Debian is in deep freeze and
> > packaging 19.04 thus out of scope.
>
> I've investigated a bit and it's not an Okular issue, but one in the
> Qt print dialog with printers that don't have PPD files. It can be
> reproduced e.g. with kate just the same and Brian even mentioned in
> the initial report that qpdfview is affected as well.
>
> The issue has been fixed upstream (qtbase) with the following commit
> (so that's what would have to be backported):
>
>
>     commit 84cc8d0badb4abc3c9a96d59c61dddce916a216c
>     Author: Albert Astals Cid <[hidden email]>
>     Date:   Mon Feb 5 09:20:20 2018 +0100
>
>         cups: Support raw printers
>
>         They don't have a ppd but we don't *really* need a ppd to just
> print
>
>         Change-Id: Idf6b6dafc19420a511b057194488e2170cae4d70
>
>
> This probably also fixes #911702, but I didn't test that explicitly.

Michael, thank you are lot for your research which made that bug report
actionable.

Of course there may be another bug in there: When one printer cannot be
used for some reason, it should not automatically switch to another one.
But nonetheless the commit you pointed out looks like it can really help
here.

Best,
--
Martin

Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Michael Weghorn
> Michael, thank you are lot for your research which made that bug report
> actionable.
>
> Of course there may be another bug in there: When one printer cannot be
> used for some reason, it should not automatically switch to another one.
> But nonetheless the commit you pointed out looks like it can really help
> here.

Yes, after taking a quick glance at the commit again, I think that this
other bug you mention should also be fixed by that commit. Previously,
the currently selected printer (variable 'm_name' etc.) would just not
be reassigned a new value (the newly selected printer) if a non-PPD
printer was selected. Thus, the last printer having a PPD that was
previously selected in the dialog would be the target of the print job.
The commit changes this.


Regards,
  Michael


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Dmitry Shachnev-3
In reply to this post by Michael Weghorn
Hi Michael and all!

On Sat, Jun 15, 2019 at 11:52:08PM +0200, Michael Weghorn wrote:

> I've investigated a bit and it's not an Okular issue, but one in the Qt
> print dialog with printers that don't have PPD files. It can be
> reproduced e.g. with kate just the same and Brian even mentioned in the
> initial report that qpdfview is affected as well.
>
> The issue has been fixed upstream (qtbase) with the following commit (so
> that's what would have to be backported):
>
>     commit 84cc8d0badb4abc3c9a96d59c61dddce916a216c
>     Author: Albert Astals Cid <[hidden email]>
>     Date:   Mon Feb 5 09:20:20 2018 +0100
>
>         cups: Support raw printers
>
>         They don't have a ppd but we don't *really* need a ppd to just
>         print
>
>         Change-Id: Idf6b6dafc19420a511b057194488e2170cae4d70
Thanks a lot for finding the commit which fixes this bug!

I have uploaded a new version of qtbase to unstable today, which has
it backported.

Can you please test that it really fixes the bug for you? If yes,
I will file an unblock request for this upload.

> This probably also fixes #911702, but I didn't test that explicitly.

If someone tests that too, it would also be nice.

--
Dmitry Shachnev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#911844: okular: Prints to the wrong printer

Brian Potkin-2
On Sun 16 Jun 2019 at 20:30:05 +0300, Dmitry Shachnev wrote:

> Hi Michael and all!
>
> On Sat, Jun 15, 2019 at 11:52:08PM +0200, Michael Weghorn wrote:
> > I've investigated a bit and it's not an Okular issue, but one in the Qt
> > print dialog with printers that don't have PPD files. It can be
> > reproduced e.g. with kate just the same and Brian even mentioned in the
> > initial report that qpdfview is affected as well.
> >
> > The issue has been fixed upstream (qtbase) with the following commit (so
> > that's what would have to be backported):
> >
> >     commit 84cc8d0badb4abc3c9a96d59c61dddce916a216c
> >     Author: Albert Astals Cid <[hidden email]>
> >     Date:   Mon Feb 5 09:20:20 2018 +0100
> >
> >         cups: Support raw printers
> >
> >         They don't have a ppd but we don't *really* need a ppd to just
> >         print
> >
> >         Change-Id: Idf6b6dafc19420a511b057194488e2170cae4d70
>
> Thanks a lot for finding the commit which fixes this bug!
>
> I have uploaded a new version of qtbase to unstable today, which has
> it backported.
>
> Can you please test that it really fixes the bug for you? If yes,
> I will file an unblock request for this upload.
>
> > This probably also fixes #911702, but I didn't test that explicitly.
>
> If someone tests that too, it would also be nice.

A couple of quick tests and it seems to me that #911844 and #911702
have been fixed with this upload.

Regards,

Brian.

Reply | Threaded
Open this post in threaded view
|

Bug#911702: Bug#911844: okular: Prints to the wrong printer

Dmitry Shachnev-3
On Sun, Jun 16, 2019 at 10:45:29PM +0100, Brian Potkin wrote:
> > I have uploaded a new version of qtbase to unstable today, which has
> > it backported.
> >
> > Can you please test that it really fixes the bug for you? If yes,
> > I will file an unblock request for this upload.
>
> A couple of quick tests and it seems to me that #911844 and #911702
> have been fixed with this upload.

Thanks for testing it!

I am marking bug 911702 as fixed now, and will file an unblock request
soon (to make the fix accepted into Buster).

--
Dmitry Shachnev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#911702: Bug#911844: okular: Prints to the wrong printer

Lisandro Damián Nicanor Pérez Meyer-2
Thank you all!!!

El lun., 17 jun. 2019 04:06, Dmitry Shachnev <[hidden email]> escribió:
On Sun, Jun 16, 2019 at 10:45:29PM +0100, Brian Potkin wrote:
> > I have uploaded a new version of qtbase to unstable today, which has
> > it backported.
> >
> > Can you please test that it really fixes the bug for you? If yes,
> > I will file an unblock request for this upload.
>
> A couple of quick tests and it seems to me that #911844 and #911702
> have been fixed with this upload.

Thanks for testing it!

I am marking bug 911702 as fixed now, and will file an unblock request
soon (to make the fix accepted into Buster).

--
Dmitry Shachnev