• gs 'exploit'?

    From luser droog@21:1/5 to All on Mon Sep 9 15:02:41 2019
    https://gist.github.com/rebirthwyw/d401fc375620d4497cc993045736a168

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From luser droog@21:1/5 to luser droog on Mon Sep 9 20:17:19 2019
    On Monday, September 9, 2019 at 5:02:42 PM UTC-5, luser droog wrote:
    https://gist.github.com/rebirthwyw/d401fc375620d4497cc993045736a168

    I'm not sure I entirely get it. Are the doubled brackets intended to "deactivate" the code so it doesn't actually do anything unless modified? That's the only thing I can think of.

    It appears this can only be used when the pdf device is active.
    So if you process to ps2 first and then run the "clean" ps output
    to make a pdf, that would completely invalidate the entire approach
    here. If this technique is used, there are limits to what can be done.
    So the permissions of the 'gs' binary are important.

    YMMV IANASA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From luser droog@21:1/5 to luser droog on Mon Sep 9 20:20:16 2019
    On Monday, September 9, 2019 at 10:17:20 PM UTC-5, luser droog wrote:
    On Monday, September 9, 2019 at 5:02:42 PM UTC-5, luser droog wrote:
    https://gist.github.com/rebirthwyw/d401fc375620d4497cc993045736a168

    I'm not sure I entirely get it. Are the doubled brackets intended to "deactivate" the code so it doesn't actually do anything unless modified? That's the only thing I can think of.

    It appears this can only be used when the pdf device is active.
    So if you process to ps2 first and then run the "clean" ps output
    to make a pdf, that would completely invalidate the entire approach
    here. If this technique is used, there are limits to what can be done.
    So the permissions of the 'gs' binary are important.

    YMMV IANASA

    Screening should be easy. Bona fide documents should never be poking
    into /.pdf* . Although now thas I say that....sigh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ken@21:1/5 to All on Mon Sep 16 08:12:37 2019
    In article <bee1f452-c660-4deb-b86c-5bc76a608ef6@googlegroups.com>, luser.droog@gmail.com says...

    On Monday, September 9, 2019 at 10:17:20 PM UTC-5, luser droog wrote:
    On Monday, September 9, 2019 at 5:02:42 PM UTC-5, luser droog wrote:
    https://gist.github.com/rebirthwyw/d401fc375620d4497cc993045736a168

    I'm not sure I entirely get it. Are the doubled brackets intended to "deactivate" the code so it doesn't actually do anything unless modified? That's the only thing I can think of.

    It appears this can only be used when the pdf device is active.
    So if you process to ps2 first and then run the "clean" ps output
    to make a pdf, that would completely invalidate the entire approach
    here. If this technique is used, there are limits to what can be done.
    So the permissions of the 'gs' binary are important.

    YMMV IANASA

    Screening should be easy. Bona fide documents should never be poking
    into /.pdf* . Although now thas I say that....sigh

    It was fixed some time back, which is why its now public.

    Probably this commit :

    http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h= 885444fcbe10dc42787ecb76686c8ee4dd33bf33

    or this one:

    http://git.ghostscript.com/? p=ghostpdl.git;a=commit;h=cd1b1cacadac2479e291efe611979bdc1b3bdb19


    All the main package repositories should by now have fixed binaries
    available, and the forthcoming 9.28 release won't suffer from the
    problem, even if you do manage to get a definition of .forceput, since
    the file permissions are now handled outside the PostScript environment.
    This entire class of exploit simply won't work any more.

    That said, we don't want people playing with non-standard PostScript
    functions, so one of the things we've been doing is removing them, or
    making them inaccessible, which is why those commits above were done,
    even though the exploit no longer works.


    As to how it works, its complicated. Its basically abusing the
    PostScript error handler, then provoking an error in a specific
    function, part of the PDF interpreter code. When that happens a
    PostScript procedure is left on the stack and that procedure contains an operator. By knowing how the procedure is constructed the code carefully
    picks that operator out, and then assigns it to its original name
    (/.forecput). It then uses that to write to a read-only dictionary,
    overwriting the file access permissions.

    The remainder of the program is just there to make it look pretty, it
    does get in the way of fixing these sorts of problems, because it
    obscures the main point. The reason its done like that is because the
    original author who understood the code write it that way, the several
    versions knocking around using other operators were uncovered by people
    who may not have really understood the PostScript, they just searched
    through the Ghostscritp support code looking for .forceput and then
    inserting that function in place of the original one.


    Apologies for the slow response, I've been on vacation.


    Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From luser droog@21:1/5 to ken on Tue Sep 17 12:22:14 2019
    On Monday, September 16, 2019 at 2:12:44 AM UTC-5, ken wrote:

    Apologies for the slow response, I've been on vacation.


    Ken

    No problem, thanks for the info. I realize now that I ought to
    have emailed you directly just in case this was sensitive. I learned
    about it from a question that popped up about my debugger program.

    Josh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ken@21:1/5 to All on Wed Sep 18 15:19:10 2019
    In article <0f031aa2-0c37-4f5e-9784-edc7a736bff7@googlegroups.com>, luser.droog@gmail.com says...

    On Monday, September 16, 2019 at 2:12:44 AM UTC-5, ken wrote:

    Apologies for the slow response, I've been on vacation.


    Ken

    No problem, thanks for the info. I realize now that I ought to
    have emailed you directly just in case this was sensitive.

    Its a public disclosure so it can't really be sensitive :-)

    There's a CVE for it somewhere, but I can't recall the number offhand


    Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From luser droog@21:1/5 to ken on Sun Oct 13 02:14:33 2019
    On Wednesday, September 18, 2019 at 9:19:14 AM UTC-5, ken wrote:
    In article <0f031aa2-0c37-4f5e-9784-edc7a736bff7@googlegroups.com>, luser.droog@gmail.com says...

    On Monday, September 16, 2019 at 2:12:44 AM UTC-5, ken wrote:

    Apologies for the slow response, I've been on vacation.


    Ken

    No problem, thanks for the info. I realize now that I ought to
    have emailed you directly just in case this was sensitive.

    Its a public disclosure so it can't really be sensitive :-)

    There's a CVE for it somewhere, but I can't recall the number offhand


    Ken

    Well, that's a relief but I learned about it from a random email from someone whose name I can't read (because I don't know the language). So, I'm still considering posting this thread as a poor decision. Despite the innocent result, I did not make the best choice based on what I knew at the time.

    But it is all very interesting. I played with the code a little bit, but without actually reading the gs source to find the relevant code being
    prodded. But it is curious that the error has to trip twice before the
    payload is left on the stack.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)