ptrace and pokerstars

Bug #636278 reported by mycl on 2010-09-12
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Wine
Fix Released
Medium
wine1.2 (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: wine1.2

Some Windows programs use ptrace pretty unexpectedly. An example is PokerStars.

This program worked fine under Lucid but under Maverick it fails to connect to the servers. The reason for this is a new security "feature" in maverick. The file:

/etc/sysctl.d/10-ptrace.conf

sets

kernel.yama.ptrace_scope = 1

This downside of this is that programs like gdb, strace and valgrind cannot attach to processes. This might be okay because the users of these programs will be sophisticated enough to use sysctl if they really need the functionality.

Users of wine are not necessarily sophisticated. They will just see Windows programs that worked in Lucid not working in Maverick and think Maverick sucks.

A work-around for this is to add the capability cap_sys_ptrace to wineserver using the command:

sudo setcap cap_sys_ptrace=eip /usr/bin/wineserver

I would like to suggest that this command be added to the wine install script. Even though it opens a security hole, I think it is very important for functionality. There is no way for the wine project or for the developers of thousands of Windows applications to fix this.

This should apply to packages wine1.2, wine1.3 and wine-PPA packages. Also wine will have to depend on the package setcap

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: wine1.2 1.2-0ubuntu5
ProcVersionSignature: Ubuntu 2.6.35-20.29-generic 2.6.35.4
Uname: Linux 2.6.35-20-generic x86_64
Architecture: amd64
Date: Sun Sep 12 03:00:13 2010
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: wine1.2

I don't see what can simply be done here, as Linux kernel evolution forbids a debugger to attach to a running program

the "easy" solution would be to let wineserver get the ptrace capability

the other only viable solution would be to modify the current process startup scheme so that wineserver (which is the only place where we call ptrace) is the parent (or grand*-parent) of every wine process

anyway, issue is located in wineserver, not winedbg (so changed component)

From the wiki, it seems like this can be worked around with a runtime override:

This behavior is controlled via the /proc/sys/kernel/yama/ptrace_scope sysctl value. The default is "1" to block non-child ptrace. A value of "0" restores the prior more permissive behavior, which may be more appropriate for some development systems and servers with only admin accounts. Using "sudo" can also grant temporarily ptrace permissions via the CAP_SYS_PTRACE capability, though this method allows the ptrace of any process.

This can also probably be set with a variable in /etc/sysctl.d/

I don't think setting /proc/sys/kernel/yama/ptrace_scope is a viable workaround

let's consider three regular cases of wine usage:
A/ a program crashes, and default fault handler starts winedbg on this process
B/ a program sets its own stack unwinder (likely in a fault handler)
C/ a programmer fires winedbg foo

in all three cases above, the calls to ptrace are made inside wineserver, so, in all the cases, the unix process (wineserver) which does the calls to ptrace is the (grand*)-parent of the process being ptraced
as a conclusion, installing Wine on ubuntu should reset ptrace_scope to 0, which is not acceptable IMO to cover the cases A, B and C (setting ptrace_scope to 0 could be acceptable in usecase C, for developpers)

so we need a better (finer grain) solution:
- either rearchitecture Wine process management so that wineserver is always a (grand*)-parent of any wine process (oouch)
- rework the kernel evolution so that an exec can get the ptrace_scope capability (I assume gdb is likely to ask for the same stuff), and set it to wineserver

A+

Please note that this breaks World of Warcraft (all versions). With ptrace protection set to ON, logging in results in an instant crash.

(In reply to comment #3)
> I don't think setting /proc/sys/kernel/yama/ptrace_scope is a viable workaround
>
> let's consider three regular cases of wine usage:
> A/ a program crashes, and default fault handler starts winedbg on this process
> B/ a program sets its own stack unwinder (likely in a fault handler)
> C/ a programmer fires winedbg foo

I didn't analyse anything just yet but it just hit me that the crash-on-login is likely due to warden looking around the game.

Seeing as Warden is a different process than wow; with your solution, it would have the same grandparent (wineserver), but would it be looking at WoW's memory (a sister process) or wineserver's memory?
Wouldn't it still crash if it looked at WoW's memory?

mycl (415fox) wrote :

Binary package hint: wine1.2

Some Windows programs use ptrace pretty unexpectedly. An example is PokerStars.

This program worked fine under Lucid but under Maverick it fails to connect to the servers. The reason for this is a new security "feature" in maverick. The file:

/etc/sysctl.d/10-ptrace.conf

sets

kernel.yama.ptrace_scope = 1

This downside of this is that programs like gdb, strace and valgrind cannot attach to processes. This might be okay because the users of these programs will be sophisticated enough to use sysctl if they really need the functionality.

Users of wine are not necessarily sophisticated. They will just see Windows programs that worked in Lucid not working in Maverick and think Maverick sucks.

A work-around for this is to add the capability cap_sys_ptrace to wineserver using the command:

sudo setcap cap_sys_ptrace=eip /usr/bin/wineserver

I would like to suggest that this command be added to the wine install script. Even though it opens a security hole, I think it is very important for functionality. There is no way for the wine project or for the developers of thousands of Windows applications to fix this.

This should apply to packages wine1.2, wine1.3 and wine-PPA packages. Also wine will have to depend on the package setcap

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: wine1.2 1.2-0ubuntu5
ProcVersionSignature: Ubuntu 2.6.35-20.29-generic 2.6.35.4
Uname: Linux 2.6.35-20-generic x86_64
Architecture: amd64
Date: Sun Sep 12 03:00:13 2010
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: wine1.2

mycl (415fox) wrote :
Changed in wine:
importance: Unknown → Medium
status: Unknown → New
In , Kees Cook (kees) wrote :

Ubuntu has added prctl(PR_SET_PTRACER, debugger_pid, 0, 0, 0); as the way to declare PTRACE relationships for crash handlers (or wardens). For an example, see how kdelibs was patched:

http://launchpadlibrarian.net/51487035/kde4libs_4%3A4.4.90-0ubuntu2_4%3A4.4.90-0ubuntu3.diff.gz

It should be possible for a process to specify which process families are allowed to PTRACE it.

(In reply to comment #6)
> Ubuntu has added prctl(PR_SET_PTRACER, debugger_pid, 0, 0, 0); as the way to
> declare PTRACE relationships for crash handlers (or wardens). For an example,
> see how kdelibs was patched:
>
> http://launchpadlibrarian.net/51487035/kde4libs_4%3A4.4.90-0ubuntu2_4%3A4.4.90-0ubuntu3.diff.gz
>
> It should be possible for a process to specify which process families are
> allowed to PTRACE it.

Did PR_SET_PTRACER actually make it into the mainline kernel then? 0x59616d61 / "Yama" certainly looks magic.

Unfortunately no, PR_SET_PTRACER is not upstream yet. But that's what's nice about prctl(), it'll just ignore unknown options.

Thank you for posting this bug.

Does this occur in newest WINE?

Changed in wine1.2 (Ubuntu):
status: New → Incomplete

*** Bug 24401 has been marked as a duplicate of this bug. ***

Worst-case situation would be to have all Wine applications just give up PTRACE protections at start-time by declaring that init and all children can PTRACE_ATTACH:

#ifndef PR_SET_PTRACER
# define PR_SET_PTRACER 0x59616d61
#endif
prctl(PR_SET_PTRACER, 1, 0, 0, 0);

Yes. It occurs in in wine1.2 and wine1.3 and the wine from git.

There's some talk that the capability cap_sys_ptrace could be fixed by
rearchitecting wine so that one process owns all of the others.
However, in order to implement ICMP it also needs cap_net_raw -- and
maybe there's some more wine functionality that needs capabilities I
haven't identified yet.

The only thing the wine project could do to fix that is to add
'setcap' to their 'make install'. But that would only fix wine built
from source. To fix it in Ubuntu, the package maintainer needs to add
setcap to the install script.

On Mon, Sep 13, 2010 at 9:47 PM, rusivi1 <email address hidden> wrote:
> Thank you for posting this bug.
>
> Does this occur in newest WINE?
>
> ** Changed in: wine1.2 (Ubuntu)
>       Status: New => Incomplete
>
> --
> ptrace and pokerstars
> https://bugs.launchpad.net/bugs/636278
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

-
Michael

Changed in wine1.2 (Ubuntu):
status: Incomplete → New

When switching to Maverick, I noticed many games ceased to work (such as Starcraft 2) ; I worked around the issue by editing /etc/sysctl.d/10-ptrace.conf and setting kernel.yama.ptrace_scope = 0.

Thanks for the tip, even though I guess this change may have other consequences...

(In reply to comment #11)
> When switching to Maverick, I noticed many games ceased to work (such as
> Starcraft 2) ; I worked around the issue by editing
> /etc/sysctl.d/10-ptrace.conf and setting kernel.yama.ptrace_scope = 0.
>
> Thanks for the tip, even though I guess this change may have other
> consequences...

The release notes for maverick meerkat comment on that ptrace change:
http://www.ubuntu.com/content/maverick-meerkat-alpha-3#Linux%20kernel%202.6.35

I committed a workaround, please test.

(In reply to comment #13)
> I committed a workaround, please test.

Works. "Fixed" by 9227eb2c9d6f0cecbabcb54cc25b5691f544b0f4.

Nominating for 1.2.1

*** This bug has been confirmed by popular vote. ***

Closing bugs fixed in 1.3.4.

Changed in wine:
status: New → Fix Released
Scott Ritchie (scottritchie) wrote :

Should be gone in Wine 1.3.4 (now building in PPA), as well as Wine 1.2.1 (due out next week, hopefully I can shove it into Maverick at the last minute - if not Stable Release Update)

Removing 1.2.x milestone from bugs fixed in 1.2.1.

Running 10.10... updated ptrace... Stuck at 'connected'...

Initially would get the WINE error... after ptrace fix; was able to put credentials in... now, stuck at 'connected'.... Anyone else with similar issues?

I'm realy new to Ubuntu and Linux. I've changed my OS from Mac and I'm really happy about it but I have no clue how to debug. Can anyone explain step by step how I use this debug in Ubuntu?

This issue has been fixed in Wine, if you're still having problems in Ubuntu go here: https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/632206 -- the package has not yet hit the automatic updates, however there are instructions there for enabling the proposed updates repository and giving a test result so it can happen automatically for others.

It should be noted that this Ubuntu breakage will make some of the Wine
regression tests impossible.

Alright. I downloaded the new Wine 1.3 and the stuff works. Counter strike still runs slow in the in game play, but I'm not sure if thats wine or my computer. I will try it on a different (bigger) mac and see if that works better. Thank you so much for the help.

Nicolai

xtrip (xtrip) wrote :

It concern also Crossover Game 9.x (Flatout 2 D2D installation)
If i set /proc/sys/kernel/yama/ptrace_scope to 0 i'm again able to play with. Pokerstars too.
(echo 0 | tee /proc/sys/kernel/yama/ptrace_scope)

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Michael

Michael Fox
Senior Test Engineer at Cavium Networks
San Francisco Bay Area

Confirm that you know Michael Fox
https://www.linkedin.com/e/-xav3h6-gnt80kc6-3v/isd/2912214500/H0fgzedp/

--
(c) 2011, LinkedIn Corporation

*** Bug 24140 has been marked as a duplicate of this bug. ***

Changed in wine1.2 (Ubuntu):
status: New → Fix Released

Posting here to help other people like me who had been searching for the correct bug report about yet another ptrace breakage that happen in Ubuntu 12.04+: it is bug #30410.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.