On Thu, 10 Mar 2022 09:59:40 -0500, Dario Niedermann <[email protected]> wrote:

I just randomly found out that running xpdf instances are connecting via https to unknown internet hosts:

-----
$ lsof -i:https
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
xpdf 4548 ndr 60u IPv4 3240798 0t0 TCP myhost:60178->151.101.1.140:https (CLOSE_WAIT)
xpdf 4548 ndr 62u IPv4 3241136 0t0 TCP myhost:54798->151.101.193.140:https (CLOSE_WAIT)
xpdf 4548 ndr 64u IPv4 3241163 0t0 TCP myhost:59904->151.101.65.140:https (CLOSE_WAIT)
xpdf 4548 ndr 66u IPv4 3241168 0t0 TCP myhost:58196->151.101.114.49:https (CLOSE_WAIT)
xpdf 4548 ndr 67u IPv4 3242068 0t0 TCP myhost:37120->151.101.0.95:https (CLOSE_WAIT)
xpdf 4548 ndr 68u IPv4 3241177 0t0 TCP myhost:44826->151.101.66.49:https (CLOSE_WAIT)
xpdf 4548 ndr 69u IPv4 3242069 0t0 TCP myhost:60520->104.16.149.64:https (CLOSE_WAIT)
xpdf 4548 ndr 78u IPv4 3241196 0t0 TCP myhost:58432->104.16.19.94:https (CLOSE_WAIT)
xpdf 4548 ndr 80u IPv4 3241189 0t0 TCP myhost:60516->104.16.149.64:https (CLOSE_WAIT)
[...]
-----

I can't think of a good, non-malicious explanation to this...
What does everyone think?

Those ip addresses owned by Fastly and Cloudfare, so no easy way to find who's site it's trying to contact.

I just tested xpdf on one of my Mageia 7 installs using strace and it is not making any such calls. Also tested without strace using lsof.

Anything in the document that might be using resources from those sites?

It's unlikely to be an infected xpdf, more likely to be something in the document.

Regards, Dave Hodgins

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

David W. Hodgins <[email protected]> wrote:

It's unlikely to be an infected xpdf, more likely to be something in
the document.

I think you may be right. Looking more closely at the lsof output,
I later noted it was just one of the xpdf instances making those calls
(same PID). Now unfortunately I closed all instances, so I'm trying to
find again which file might have been guilty.

It's a bit troubling if a PDF file can do this, though. It can be used
at the very least as a tracking mechanism (that IP is reading this file)
or - who knows - maybe even download malicious content?

--
Dario Niedermann -:- finger my email address for PGP key, etc.

Also on the Internet at: <gopher://darioniedermann.it/>
<https://www.darioniedermann.it/>

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

On 2022-03-10 15:59, Dario Niedermann wrote:

I just randomly found out that running xpdf instances are connecting via https to unknown internet hosts:

-----
$ lsof -i:https
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
xpdf 4548 ndr 60u IPv4 3240798 0t0 TCP myhost:60178->151.101.1.140:https (CLOSE_WAIT)
xpdf 4548 ndr 62u IPv4 3241136 0t0 TCP myhost:54798->151.101.193.140:https (CLOSE_WAIT)
xpdf 4548 ndr 64u IPv4 3241163 0t0 TCP myhost:59904->151.101.65.140:https (CLOSE_WAIT)
xpdf 4548 ndr 66u IPv4 3241168 0t0 TCP myhost:58196->151.101.114.49:https (CLOSE_WAIT)
xpdf 4548 ndr 67u IPv4 3242068 0t0 TCP myhost:37120->151.101.0.95:https (CLOSE_WAIT)
xpdf 4548 ndr 68u IPv4 3241177 0t0 TCP myhost:44826->151.101.66.49:https (CLOSE_WAIT)
xpdf 4548 ndr 69u IPv4 3242069 0t0 TCP myhost:60520->104.16.149.64:https (CLOSE_WAIT)
xpdf 4548 ndr 78u IPv4 3241196 0t0 TCP myhost:58432->104.16.19.94:https (CLOSE_WAIT)
xpdf 4548 ndr 80u IPv4 3241189 0t0 TCP myhost:60516->104.16.149.64:https (CLOSE_WAIT)
[...]
-----

I can't think of a good, non-malicious explanation to this...
What does everyone think?

Well, I tried to reproduce this and could not.


cer@Telcontar:~> lsof -i:https | grep xpdf
cer@Telcontar:~>

We can find information about those IP you list with "whois".

The first two:

NetRange: 151.101.0.0 - 151.101.255.255
CIDR: 151.101.0.0/16
NetName: SKYCA-3
NetHandle: NET-151-101-0-0-1
Parent: RIPE-ERX-151 (NET-151-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Fastly (SKYCA-3)
RegDate: 2016-02-01
Updated: 2021-12-14
Ref: https://rdap.arin.net/registry/ip/151.101.0.0


OrgName: Fastly
OrgId: SKYCA-3
Address: PO Box 78266
City: San Francisco
StateProv: CA
PostalCode: 94107
Country: US
RegDate: 2011-09-16
Updated: 2021-09-20
Ref: https://rdap.arin.net/registry/entity/SKYCA-3


The last one:

NetRange: 104.16.0.0 - 104.31.255.255
CIDR: 104.16.0.0/12
NetName: CLOUDFLARENET
NetHandle: NET-104-16-0-0-1
Parent: NET104 (NET-104-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS13335
Organization: Cloudflare, Inc. (CLOUD14)
RegDate: 2014-03-28
Updated: 2021-05-26
Comment: All Cloudflare abuse reporting can be done via https://www.cloudflare.com/abuse
Ref: https://rdap.arin.net/registry/ip/104.16.0.0



OrgName: Cloudflare, Inc.
OrgId: CLOUD14
Address: 101 Townsend Street
City: San Francisco
StateProv: CA
PostalCode: 94107
Country: US
RegDate: 2010-07-09
Updated: 2021-07-01
Ref: https://rdap.arin.net/registry/entity/CLOUD14




--
Cheers, Carlos.

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

On 2022-03-11 11:08, Dario Niedermann wrote:

David W. Hodgins <[email protected]> wrote:

It's unlikely to be an infected xpdf, more likely to be something in
the document.

I think you may be right. Looking more closely at the lsof output,
I later noted it was just one of the xpdf instances making those calls
(same PID). Now unfortunately I closed all instances, so I'm trying to
find again which file might have been guilty.

It's a bit troubling if a PDF file can do this, though. It can be used
at the very least as a tracking mechanism (that IP is reading this file)
or - who knows - maybe even download malicious content?

This has been known for long (used typically for tracking who reads a
document, or for authorizations), but I thought xpdf was not capable of
doing it. I thought it needed the scripting in adobe reader.


--
Cheers,
Carlos E.R.

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