这是一个创建于 1220 天前的主题，其中的信息可能已经有所发展或是发生改变。
这个情况是偶然间发现的，具体情况如下：
测试环境
- 被控端 X 是 MacOS，安装了 ToDesk 官网最新版。
- 控制端 A 是 MacOS，安装了 ToDesk 官网最新版。（使用密码连接过被控端 X，后正常断开）
- 控制端 B 是 MacOS，安装了 ToDesk 官网最新版。（从未连接过被控端 X ）
- 控制端 B-VM 是 Win10 虚拟机，运行在 B 上，安装了 ToDesk 官网最新版。（从未连接过被控端 X ）
- 被控端 X 、控制端 A 、控制端 B 都不在一个网络。
测试结果
- 控制端 B 无需密码即可连接，多次验证都可以。
- 控制端 B-VM 需要密码才能连接。
测试结果录屏
题外话
从现象来看连接密码似乎并没有作为端到端加密密钥的一部分（这种设计真的没问题么？），当认证节点出现问题时直接允许控制端与被控端建立连接。当然这些只是我的猜测，并没有深入分析，虽然从事的是信息安全方向，但术业有专攻嘛，就留给感兴趣的小伙伴了～
第 1 条附言 · 2021-07-09 07:58:07 +08:00
看到评论说可能是 icloud 钥匙串同步 导致的，我这里再补充一些信息：
- X、A、B 三台设备都登陆了同一个 AppleID
- X、A、B 三台设备的 ToDesk 均未登录账号
- 回想了一下昨天的情形，设备 A 连接被控端 X 时，每次都是需要输入密码的（连接成功后，断开）。为谨慎起见，我用设备 B 连接 B-VM 又做了几次测试，可以确定：第一次连接成功后，下一次连接仍需要密码。
第 2 条附言 · 2021-07-09 12:09:41 +08:00
本来发这个贴也是为了探讨出现这个问题的可能性，结果倒好，直接一上来扣帽子。 既然如此，都是搞信息安全的，我就不说废话了。
本人对以下内容负责：
- 视频未经过剪辑，使用的是 MacOS 自带的录屏功能（MOV已保存），上传的 GIF 图片使用的是 Ruby 脚本转的。
- 昨天偶然发现这个情况后，想分析下通信协议，所以对该过程进行了抓包，PCAP 已经保存。
- 至于“自动保存上次连接记录”这个功能，此前不清楚，看到评论里说了后，我再次确认了设备 A、设备 B、设备B-VM “未开启该功能”。（很遗憾，这部分没能在视频中体现出来）
其他的，既然你们（特指开发者）你们都有数据，建议好好看看相关日志记录。 同理，我也保留追究你们恶意中伤/诬陷我的权利;)
第 3 条附言 · 2021-07-09 15:04:10 +08:00
再次补充:
首先自我检讨下，之前言语太武断，现修改为 ToDesk "可能"存在安全漏洞。再说明下，我至始至终都没有在设备 B 上输入过连接密码，在这种情况下，不需要密码就可以连接，且多次复现，把这定义为安全漏洞，我不认为有何不妥当。
其次，今天中午又成功复现，吸取了上次"恶心剪辑"的教训，这次录屏过程中把 ToDesk 的设置界面(未开启记录历史连接密码)也进行了展示。
如果有必要的话，我会把新的录屏内容放出 。(CNVD 也行，不太想暴露我的 ID)
最后，正如 V 友说的，日志有时候不一定可信。再次建议开发者"先"好好排查，不管是客户端侧还是服务侧，内部排查完，再来说我是不是在"黑"你们产品。
最后的最后，不要再说我是友商派来的、利益相关啥的，我就是个路人甲，谢谢。
首先自我检讨下，之前言语太武断，现修改为 ToDesk "可能"存在安全漏洞。再说明下，我至始至终都没有在设备 B 上输入过连接密码，在这种情况下，不需要密码就可以连接，且多次复现，把这定义为安全漏洞，我不认为有何不妥当。
其次，今天中午又成功复现，吸取了上次"恶心剪辑"的教训，这次录屏过程中把 ToDesk 的设置界面(未开启记录历史连接密码)也进行了展示。
如果有必要的话，我会把新的录屏内容放出 。(CNVD 也行，不太想暴露我的 ID)
最后，正如 V 友说的，日志有时候不一定可信。再次建议开发者"先"好好排查，不管是客户端侧还是服务侧，内部排查完，再来说我是不是在"黑"你们产品。
最后的最后，不要再说我是友商派来的、利益相关啥的，我就是个路人甲，谢谢。
第 4 条附言 · 2021-07-10 10:10:26 +08:00
看到开发者发的联系信息，我尝试在和对方联系了。后续如果有任何进展，不管是误会还是BUG，我都会附言。
顺便解答某些 V 友的一些质疑：
Q1：为什么在 V 站发帖？
常在 V 站上看到 ToDesk 官方宣传贴，我亦是从 V 站上了解到这款软件并开始使用的，自然认为在此处发帖最容易被官方开发者看到。
Q2：不充分的测试就下结论，想搞个大新闻？
并没有。如果你仔细看过帖子详情，我是尽量用客观的语言描述复现场景以及测试上下文，也是期望尽可能帮助官方发现并定位问题所在的。常规情况下的漏洞测试流程我很清楚，如果一个通用型漏洞，没有稳定的POC，我是不敢妄下结论和提报 CVE 的。但是 ToDesk 的这个情况不太一样，如果只是误会还好，一旦是真的偶发性漏洞，那就是大事。虽然可以在我的某台设备上可以稳定复现，但在其他设备上又无法复现，所以我猜测这个问题的触发一定是比较苛刻的（可能和设备、网络节点、服务器缓存节点等有关），所以发帖到信息安全节点，一方面是给正在使用 ToDesk 的 V 友提个醒注意到这个情况，另一方面也是希望在降低影响面的情况下借百家之长来补充完善相关细节（能不能复现、复现概率有多大等等）。如果我是想搞个大新闻，我有必要在 V 站发么？直白点，我拍个抖音，你猜那些技术水平稍微低一些的用户（非歧视），会怎么评价？会怎么转发？
第 5 条附言 · 2021-07-10 16:51:09 +08:00
后续：
通过论坛和 ToDesk 团队负责人取得联系后，我们进行了深度测试和本地验证，发现的确是一次乌龙事件。具体事实如下：
- ToDesk 使用 chacha20 and Poly 1305 端到端加密，不存在无密码就可以连接的情况
- ToDesk 连接设备时，会优先查找保存的历史连接记录
- ToDesk 早期版本的“记住历史连接密码”密码是默认勾选的
- ToDesk 新版本去掉了这个默认选项
- ToDesk 新版本无法在 UI 下拉菜单列表中显示老版本的数据库连接记录
本次产生乌龙的原因是：我使用了 ToDesk 旧版本（默认配置），在升级新版本后，软件 UI 并没有把老版本的连接记录显示在下拉菜单中，因此产生了误会。
后续及其开发者附言详见： https://v2ex.com/t/788723
 |
1
hs0000t 2021-07-09 00:52:21 +08:00 via Android
插眼 无 Mac 等楼下复现
|
 |
2
also24 2021-07-09 01:29:55 +08:00
未有使用过这个软件，但猜测控制密码（或其它凭证）是否自动通过 iCloud 钥匙串同步了
|
 |
3
woshijidan 2021-07-09 01:58:34 +08:00 via Android  2
连过一次下次就会记住密码
|
 |
4
ashong 2021-07-09 02:34:12 +08:00 via iPhone
icloud 同步？
|
 |
5
darknoll 2021-07-09 08:03:11 +08:00
别用这玩意了，现在传个文件都要充钱
|
 |
7
NewYear 2021-07-09 09:19:55 +08:00
还在等什么，遍历全网机器啊。。。
连接自己的机器，录屏也不能证明你的密码是不是自动保存了。 |
 |
8
zhangchongjie 2021-07-09 09:27:45 +08:00
这个已经开始花钱了,不用了,找个其他替代,除了花生壳,还有其他的推荐吗
|
 |
9
fanguangwei 2021-07-09 09:29:04 +08:00 via iPhone
搞 wireguard 比这 todesk 中转流畅多了
|
 |
10
Lemeng 2021-07-09 09:30:48 +08:00
密码记录，自动连接？
|
 |
11
zsxzy 2021-07-09 09:49:30 +08:00
anydesk 挺好用的
|
 |
12
ClericPy 2021-07-09 09:51:41 +08:00
manjaro 上 CPU 超高, 不知道什么原因, 目前已经换替代品
anydesk 如果速度快点就好了 teamviewer 是我 manjaro xfce4 上唯一能解锁屏幕的, 却一直说我商用... |
 |
13
huluwa561 2021-07-09 10:03:10 +08:00 3
ToDesk 简直奇葩，有一次我更新完，用户名居然变成了我的密码
|
 |
14
kerro1990 2021-07-09 10:08:24 +08:00
ToDesk 奇奇怪怪得 bug，远程看视频居然黑屏，还是 teamviewer 好使
|
 |
17
2le OP @NewYear 如果这么容易就能复现，那开发和测试都可以开除了。至于录屏问题，确实没法 100%证明，不过当时的 PCAP 包都有保存，也算是留了一部分证据。
|
 |
18
meisen 2021-07-09 10:39:17 +08:00
昨晚在 macOS 和 iOS 上测试，不管是否同一网络，只要成功连接一次，再次连接都不需要密码。
今天起来发现 iPhone 电量快没了，打开发现 ToDesk 一直在后台运行，macOS 上未设置开机启动却在活动监视器里发现也存在。 果断卸载！ |
 |
19
xinJang 2021-07-09 11:38:29 +08:00
我都是 windows，暂时没遇到这个问题，倒是遇到另一个问题，就是我常用的设备经常被识别成新设备，每天给我发 n 封确认新设备登录的邮件
|
 |
20
PUBG98k 2021-07-09 11:43:42 +08:00 1
1.我们看到 这个视频里，总共涉及 3 个设备代码，
第一个代码是 被控的设备代码，550891299 （这台机器后面看是台 MAC 机器，后面简称 mac 被控）. 第二个 设备代码是 609039162 （这是台主控机器，运行在 mac 系统上的虚拟机里， 虚拟机里是 win10 系统，后面简称 win10 主控），第三个设备代码 886744665 （这机器充当着主控，运行在真实的 mac 系统上，后面简称 mac 主控）。 2，我们看流程图，首先，这个视频里用 win10 主控去链接 mac 被控，输入了 ID，反复了好几次，都要求输入密码，结果这个视频里没有输入密码，官方后台日志，也提供了，相关的数据 细心的观众现在大概已经清楚了，这位视频剪辑者， 首先 在 2021-07-08 23:13:08 使用 mac 主控去链接了 mac 被控，输入了被控密码，并且密码验证成功了（我们都知道在客户端勾选了记录历史密码的情况，会保存上一次链接的密码，下下次再连就不需要输入了，方便第二次链接），然后 在 2021-07-08 23:14:37 这位视频剪辑者用 win10 主控去链接 mac 被控，要求输入密码（这是正确的操作），最后，最重要的地方就是 这位视频剪辑者返回 mac 主控再次来对 mac 被控发起远程，发现成功了（因为保存历史记录的远程，没有要求你输入密码，因为在本机的历史文件中记录了上次输入的密码，所以会尝试用上次的作为这次的密码，如果对方改了密码，那这次是验证是无效的），这时候，这位视频剪辑者就开始攻击我方，说我方无须密码就可以访问被控端。 =================== 上面很乱.总结如下: 1.只有成功输入密码连接成功后,才会在历史记录下拉菜单里有保存记录. 2.后端有日志记录了,每次都有密码请求.并且验证通过   以上就是我方作为受害方对整件事情的调查结果。所有数据我方确保合法。 我们将用法律武器，来维护我们自己的利益，这位视频剪辑者望你好自为之. --------------------------------------- |
|
21
PUBG98k 2021-07-09 11:46:29 +08:00
@hs0000t
@also24 @woshijidan @ashong @waising @NewYear @zhangchongjie @fanguangwei @Lemeng @zsxzy @ClericPy @2le @meisen @xinJang |
|
22
PUBG98k 2021-07-09 11:47:13 +08:00
此视频经过剪辑处理.不知道出于什么目的..
|
 |
23
lingxi27 2021-07-09 11:53:43 +08:00
这个赛道最近被资本看好了吗？斗争这么激烈了
|
 |
24
lscho 2021-07-09 12:03:43 +08:00
前排插眼。。。
#20 的说法我怎么感觉就这么别扭呢，上来就开始动用法律武器了。。。 你只是后台看到日志要求 win10 主控输入密码，视频中没有出现输入密码的步骤，就断定录屏事剪辑过的，是不是有点太武断了？会不会存在软件 bug 问题导致用户端没有出现输入密码弹窗？而且你提供的日志里也没看到有需要主控端提供密码的记录啊。 |
 |
25
0o0O0o0O0o 2021-07-09 12:10:57 +08:00 via iPhone 1
报 bug 怎么被理解成迫害了
|
|
26
0o0O0o0O0o 2021-07-09 12:13:47 +08:00 via iPhone 9
我觉得楼主的描述相对普通用户已经相当详细了，我也相信好好沟通的话他也会配合开发者做复现，开发者团队这样的态度很不明智。
|
 |
28
debuggerx 2021-07-09 12:16:36 +08:00 22
就冲开发者的这个态度，我就不会再考虑这款软件了
|
 |
29
houzhishi 2021-07-09 12:17:19 +08:00
都是搞技术的，不要这么听风就是雨，我觉得软件操作逻辑没啥问题，应该是记住密码了，如果是安全漏洞验证，你应该尝试着登录其他人的。我也是用户，第一次登陆时肯定会要求密码的，应该是之前使用过，而且没有启用每次连接更换密码。标题有问题，就别怪上面老哥说要起诉你。
|
|
30
houzhishi 2021-07-09 12:21:54 +08:00
既然你是搞信息安全的，我就假定你的漏洞是真实的，你的流程也不符合规范，你应该提交相关复现细节，提交 cnvd 或者联系官方，你这样的确有法律风险。
|
 |
31
liprais 2021-07-09 12:25:44 +08:00
todesk 的人脑子里装的都是啥......
|
|
32
darknoll 2021-07-09 12:27:42 +08:00
千万不要再使用这个软件了，真的是非常的垃圾，搞不好整点后门啥的
|
 |
33
ncepuzs 2021-07-09 12:58:37 +08:00
建议把录制的视频放出来一并甩脸上……
|
 |
34
angkimi 2021-07-09 12:59:13 +08:00
给各位大佬们，我都忍不住想笑了，作为 ToDesk 的用户，对这个报道还是很重视的，结合楼上老哥发的连接记录和作者的视频，其中作者有两个设备发起连接！注意关键来了：1 、23 点 14 分 20 秒视频第一个出现的设备是一个主控设备码是 [609039162] 显示连接被控设备 [550891299] 需要输入密码，这个是对的。2 、23 点 14 分 55 秒视频作者切换第二个主控设备代码是 [88644665] 同样控制 [550891299] 连接成功了，这里作者说是有漏洞。问题来了！ 3 、根据楼上（应该是官方人员）@PUBG98k 提供的连接记录来看 [88644665] 作为主控设备在 23 点 13 分 07 秒已经提示连接成功一次，这就不难说明，这是正常的，因为 todesk 成功连接一次后面是无需输入密码的！感觉是恶意中伤！如果不是恶意，建议作者还是删除，和官方人员解释一下，误会一场。大家还是要保障网络良好氛围！如果是竞争对手恶意去诋毁一家好的产品，感觉没必要，何必用诋毁去污蔑呢？这样我就建议报警吧！
最后希望大家给本回复点个赞吧！ |
|
35
angkimi 2021-07-09 13:00:55 +08:00
建议官方先截图取证
|
 |
36
binux 2021-07-09 13:09:00 +08:00 via Android 31
@angkimi 你「作为 ToDesk 的用户」在 V2EX 发的唯一一帖就是 ToDesk 的推广。
以上就是我方作为舆论操纵的受害方对你回复的调查结果。所有数据我方确保合法。这位评论者望你好自为之。 |
 |
37
minami 2021-07-09 13:09:38 +08:00 3
@angkimi #34 你这个小号未免也太明显了吧，上次登录是三百多天前，发帖记录只有一个 ToDesk 的推广贴，然后接着就是几分钟前本帖的这两个回复。V 站程序员很多，日志看不到问题不等于没有 bug，这个道理应该都是明白的，上来就是恶意中伤警告，只能说是公关灾难了
|
 |
38
ck65 2021-07-09 13:12:16 +08:00 2
智商之低，叹为观止，周末愉快
|
|
39
angkimi 2021-07-09 13:12:56 +08:00
报 bug，为什么在公众平台发帖呢？为什么标题让别人谨慎使用呢？为什么确定 todesk 存在安全漏洞呢？你和他估计是一伙的吧？这个行业看样子有一场好戏看了！看你们演！
|
 |
40
Otho 2021-07-09 13:14:08 +08:00
老哥就在论坛里发了个贴，不知道双方有没有私下沟通一下，官方这态度就不是解决问题的态度。私下好好的沟通一下，查查问题多好。
|
 |
41
oneisall8955 2021-07-09 13:21:41 +08:00 via Android
火钳刘明，有老哥复现吗？没 Mac
|
|
42
houzhishi 2021-07-09 13:23:46 +08:00
@minami 既然大家是写代码的，那你告诉我这样的认证场景，该怎么写，如果所有连接不需要认证，那么漏洞早就应该出来了，如果需要验证，那我们就需要排除到，认证中可能存在的流程问题，比如记住连接记录。标题一上来，就是发现漏洞，丝毫没有严谨而言，我看不到作为网络安全从业者的谨慎。
|
 |
43
hhacker 2021-07-09 13:24:38 +08:00
有问题 有 BUG 很正常 谁能说自己没写过 BUG， 即便用户是推测得出的不可靠的结论，也是在帮助你们改进产品，如果上面的“官方”回复确实是开发团队的回应，你们的确未能占领任何高地。
|
 |
44
boboliu 2021-07-09 13:27:58 +08:00
|
 |
45
wfd0807 2021-07-09 13:29:34 +08:00 1
看了 20 楼的回答，就这态度和理解能力，ToDesk 的标签已打，blocked
|
|
46
kerro1990 2021-07-09 13:31:30 +08:00
国产软件留后门不很正常的嘛，方便国家网监，也算是为国出力了
|
 |
48
GoRoad 2021-07-09 13:43:02 +08:00
开始了 开始了 又开始上升高度了
|
 |
49
ibegyourpardon 2021-07-09 13:48:25 +08:00
不用就对了。
|
|
50
minami 2021-07-09 13:48:37 +08:00 via Android
@houzhishi 扯开话题的本事够强啊，我只是说日志不一定可靠，你就能脑补出这么多。那我问你，你有去尝试复现吗？能复现就可能是 bug，不要拿日志没问题来说事
|
|
51
angkimi 2021-07-09 13:57:42 +08:00
真能扯，真能闹！
|
 |
52
falcon05 2021-07-09 13:59:11 +08:00 via iPhone
笑死了，这些 ToDesk 请的都是些啥猪队友😹
|
|
53
houzhishi 2021-07-09 13:59:30 +08:00
@minami 不好意思，我这边复现不了，我是 Windows 端，我脑补个锤子，是谁在脑补，我一直在说实事求是，以及严谨。mac 在家，回家后将继续尝试 mac 下的浮现。我和你是基于对开发了解的前提下，考虑，如果你觉得我是在怼你，那你可以不用回复我了。
|
 |
54
mekingname 2021-07-09 14:00:54 +08:00
不要『保留追究 xxx 的权利』，要『行使追究 xxx 的权利』
|
 |
55
dyxLike 2021-07-09 14:06:34 +08:00
吃一个瓜
|
|
56
boboliu 2021-07-09 14:07:39 +08:00
todesk 作为一个用户量还算蛮多的工具，真的出这种问题要复现恐怕也是条件苛刻的极个例才能复现，既然官方都在这了各位说复现不了的安全从业人员还是丢给官方去查吧
|
|
57
minami 2021-07-09 14:23:43 +08:00
@houzhishi #53 自己都没验过，发言里都是假设，就来说实事求是、严谨（而且“实事求是”这四个字你是第一次发，哪来的一直在说？）。语气那么冲，硬要说自己不是在怼。我算是明白为什么网上容易吵了，就是自我感觉良好又喜欢双标的人引起的。我自认为我在 37 楼的发言并没有任何问题，也没有 AT 你，你为什么会来 AT 我？
不知道贵司是什么情况，我是做 toB 产品的，日志没问题、不能被稳定复现，最后也被记 bug 是再正常不过的事情了（当然一直无法复现也不能强求）。市场报 bug 也不会心平气和的提供细节（敢质疑用户？） |
 |
58
cz5424 2021-07-09 14:41:20 +08:00 1
客观总结一下
开发者报 bug 的方式不对（如果真是 bug 的话，后果不堪设想）； ToDesk 的公关能力有限 |
|
59
houzhishi 2021-07-09 14:41:30 +08:00
@minami 哈哈哈，自我感觉良好，你是在说自己的吧。我是说我在 windows 下复现没有出现这种情况，不是没有复现，而且这是个跨平台的软件，验证握手是经过服务端的，理论上不同平台不影响验证流程。从安全角度讲，这种未授权访问的漏洞，不等于常见的 bug，需要一定的条件支持，而不是你说的这种不能复现随机的 bug 。
|
 |
60
cat9life 2021-07-09 14:43:52 +08:00
插眼围观 没发现视频有啥问题...
|
|
61
houzhishi 2021-07-09 14:49:26 +08:00
@minami 如果你是用过此软件以及有开发的经验，结合官方的日志，基本可以判断，仅仅是记住密码的问题，我是此软件的老用户，而且我比较喜欢记住密码的功能，平时使用很方便。
|
 |
62
e3rp4y 2021-07-09 14:54:41 +08:00
强力插入, 可以试试用[`Meepo`]( https://github.com/PeerXu/meepo) + SSH + RDP + VNC. 可以实现相同的功能. 并且还开源免费.
|
 |
63
no1xsyzy 2021-07-09 15:00:08 +08:00
|
|
64
houzhishi 2021-07-09 15:06:01 +08:00
@no1xsyzy 你的思路我复现了一下，即使取消勾选，之前保存的依然在，依然可以直接连接。现在回头想，复现的时候修改一下连接密码是最有效的验证软件是否存在未授权。
|
 |
65
yohole 2021-07-09 15:06:07 +08:00 1
开发者的意思就是：解决不了问题，那就解决提出问题的人
|
|
67
no1xsyzy 2021-07-09 15:10:13 +08:00 2
|
|
68
2le OP @houzhishi 你说的很对，是一种验证方式，但我目前还不会轻易尝试。如果问题出现在认证服务侧(比如 session)，修改连接密码后可能会导致 session 被重置，那么这个问题就再也无法复现了。这个时候 Dump 服务端内存才是官方应该优先做的，而不是...哎
|
|
70
no1xsyzy 2021-07-09 15:15:49 +08:00 1
|
 |
71
Linken404 2021-07-09 15:18:13 +08:00 6
之前研究 teamviewer 替代品就看到过 todesk，考虑到国产闭源产品还是没有实际尝试，并且我最后是用开源堡垒机来达到我远程的目的。
但以目前这个开发方的第一反应，至少这个产品会列在我作为用户的黑名单上了，至少他们给我的感觉完全不像是那种认真的技术人员。 |
 |
72
smilenceX 2021-07-09 15:24:55 +08:00
想说点什么，又怕被人警告“好自为之”
|
|
74
Linken404 2021-07-09 15:32:36 +08:00
有固定设备远程需求的，可以考虑用 ddns 或内网穿透+jumpserver 来代替，我就是通过家里的 jumpserver 虚拟机远程管理其它家中设备还有几个墙外的 VPS 的。
优点是安全方便，缺点是配置安装较复杂且每添加一个新节点都需要单独配置。 |
|
75
houzhishi 2021-07-09 15:34:56 +08:00 4
@2le 我进行了，对于下拉记录没有的历史情况进行复现尝试，我的操作时，本地端先勾选记住密码，然后连接，然后删除历史记录，然后取消勾选记住密码，下次登陆依然可以直接连接。这个情况完全可以理解为缓存文件导致的。
|
|
76
houzhishi 2021-07-09 15:40:51 +08:00
@2le 至于会话保存，我对场景的思考只能是可能服务器会对网络情况不好的时候会不会有一种优化的操作，当然这些是我的猜测，没有任何证据。
|
 |
77
woigghaja 2021-07-09 16:03:59 +08:00
在线吃瓜，简单点不好嘛，永远陷在猜测里面，建议楼主直接联系开发方吧，不然真的是够无聊的，一直在攻击和澄清中徘徊
|
 |
78
dingyx99 2021-07-09 16:06:49 +08:00
就这公关质量。。。。这软件不管有没有问题都可以直接拉黑了
|
 |
79
v2tudnew 2021-07-09 16:07:08 +08:00
不管是不是漏洞、后门，我反正不会在自己电脑上装任何闭源远程软件的，事实上 DDNS+VPN 或者 FRP+STCP 就可以完美解决自己的需求，至于客户？愿意用哪个就用哪个好了，反正虚拟机伺候。
|
 |
80
gitopen 2021-07-09 16:30:00 +08:00
@fanguangwei 我也用 wireguard，无奈 macOS 下不支持国内外域名分流，每次远程桌面和番墙都得来回切
|
 |
81
harwck 2021-07-09 16:40:19 +08:00 1
自從被 TeamViewer 噁心了之後只用 ZeroTier，不知道好到哪裏去了
|
 |
82
dbpe 2021-07-09 16:41:32 +08:00
Tinc + AnyDesk 不香么
|
 |
83
stcode 2021-07-09 16:56:21 +08:00
这软件公关方真是很官方的作风,上来就说别人攻击你们,用户提出问题,即便可能是误会就你这态度我也认定你们的软件有问题了
|
 |
84
MaverickLee 2021-07-09 16:58:25 +08:00
@harwck #81 TV 出什么事了？囧
|
 |
85
mercury233 2021-07-09 17:10:54 +08:00
@MaverickLee 被思马公司代理，通过恶意判为商用的方式实质上不再对个人免费
|
 |
86
yolee599 2021-07-09 17:11:36 +08:00
@PUBG98k #20 为什么不能私下好好沟通？看看是哪一方的问题，上来就法律武器。而且你说的和提供的图片，并没有说明用户已经输入密码了啊
|
|
87
woshijidan 2021-07-09 17:42:15 +08:00 via Android
@PUBG98k #21 我不是都说了 连过一次就会保存临时密码作下次使用 所以并不是 bug 什么的
|
 |
88
musi 2021-07-09 18:23:41 +08:00
不知道软件有没有问题，但可以肯定人有问题。
|
 |
89
datafeng 2021-07-09 18:35:33 +08:00
公网动态 IP 或者自己穿透然后用 rdp 不香么，搞这些乱七八糟的~~
|
 |
90
yu1u 2021-07-09 18:42:28 +08:00
看到官方这种公关态度......果断卸载了
|
 |
91
weiwenhao 2021-07-09 19:02:00 +08:00
我和楼上的各位持不同意见。
看了补充评论，这标题太偏激了，就是在没有确定的是否是漏洞的情况下已经劝大家不要使用了。 |
 |
93
terencehan 2021-07-09 19:08:14 +08:00 2
|
 |
94
weak 2021-07-09 19:10:10 +08:00 via iPhone 1
官方这态度还是尽量不要用这软件了
|
 |
95
FS1P7dJz 2021-07-09 19:12:33 +08:00 4
我只说一句
要求"严谨,详细"这是对厂家而言 用户只要不是故意伪造并且试图以此进行勒索,要挟,就谈不上所谓的法律责任 标题也许有点唬人,但这并不构成什么诽谤 这厂家已经入黑名单了 |
 |
96
zhady009 2021-07-09 19:24:04 +08:00
@weiwenhao +1 而且提交 bug 不是这样提交的吧 不知道楼上那些说"提交 bug"是什么意思 不过官方回应也是过了
|
 |
97
qfdk 2021-07-09 19:51:51 +08:00 via iPhone
别的不说 楼主态度 以及 给出复现的过程还是足够详细的. 支持楼主. 之前也看到过宣传 果然还是没必要下载了. 看了厂商的态度 感觉不大靠谱. 楼主的节点也是信息安全，并不是所有设备都能复现同样的 poc， 我感觉没有任何不妥当！
|
 |
98
Livid MOD 94
今天 ToDesk 官方的人一直在联系我，要 V2EX 删掉这个主题，或者禁止这个主题被回复。
然后你们也看到了，这个主题目前还是存在着的。 虽然我也觉得这个标题是有问题的，但是很多有技术含量的，认真的回复也为这个问题增加了更多的事实性补充。 我很耐心地回复了对方很多封邮件，而对方还是契而不舍地要 V2EX 删帖，原因之一是因为其他地方在转载。 我把我刚才最后一封邮件里的话打在这里： 软件如果产生了不符合用户预期的行为，用户就会自然产生疑问。这种疑问可能是 bug 也可能是误会。 但是你们不去解决软件的不符合预期的行为，而是这样来对我持续施压，我对你们公司也觉得非常失望。 |
 |
99
doresu 2021-07-09 20:14:05 +08:00
ToDesk 的回复实在不靠谱
|
 |
100
panda1337 2021-07-09 20:17:25 +08:00
笑死了 这些 ToDesk 的公关也太🐂了把
|
Select Language