220 40436 article Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Gutson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: more security concerns Date: Tue, 9 Oct 2018 09:57:38 -0300 Lines: 231 Approved: news@gmane.org Message-ID: References: <94d79dd7-ba3b-4bf8-91ed-e5dc02b33670@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000106e8f0577cb49f2" X-Trace: blaine.gmane.org 1539089751 18673 195.159.176.226 (9 Oct 2018 12:55:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2018 12:55:51 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDE3NBMV6UFBBUGL6LOQKGQEOINIERQ@isocpp.org Tue Oct 09 14:55:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f197.google.com ([209.85.208.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9rY6-0004gK-BW for gclcip-std-proposals@m.gmane.org; Tue, 09 Oct 2018 14:55:42 +0200 Original-Received: by mail-lj1-f197.google.com with SMTP id p6-v6sf462398ljb.0 for ; Tue, 09 Oct 2018 05:57:53 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1539089873; cv=pass; d=google.com; s=arc-20160816; b=RYofWXY2wSPH4Y0oA0mGePkV3U8nu+n0KHXeKvd0Ben6H/ljDZ5ZC5R+l9qhAYl2+Z LwlmzY8WiBtYEwI4qoPomVjmicsYFFki3gHLCleU7vcKzsTCf0qLcSEaMYVCX8PUi3wT YIT/bLF/ZNWU9Ld3HrwNjAWdwOLiveBBGkFusPxE3bUjYP2oZpYLhuC4SpAro6NnpWrt q23nhBeC02mWxUUl/FjIAyC0guIHo+9Txm2fn/+8N7zn13Lr0QvOcypqRm53dEKu8Oj6 oo9T5eCJ/Tb0cngC2ksLIwxO4sKIHB2h4Gd1kIvUUHKKuxhvIZXwmD5luGSo9RFs5Pfp v3iw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=iHZb+t3N1v3cuDbkvMS9bRvchA+3PouRKjUPHYWGTfY=; b=dkc8rx2JJnUF+y0G32NTvLX6H1LIwEWcGNCwerD3KBKzB401pBamRehmp/BzcoSsid 3OdnuT5B/VPlx0LcabBrlWqxw/DRZGqa8NSRWDNU2gjpToGx9RkWBXmm4mWX2W2w4b6n ev5J/dtNXDcDSeOJCXw3wl1VMrS+js6irTY8I42FU3pLmqDOsXwKCaqS3LQ07w21n5L4 XiJXtCvh/mx/Ft0Z+85HxlOA1CsBqgBM0tLyywn2Ho0PAOwE29aQGAbH1ShBvV+g9fB+ ip+FrEEsQcY78VM1GfiDl6X7o+OLQSUBD/idfqWrCRsEJ0bAZsnSCzWGxWrMiT1NBeO3 j9SQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KodgwLwb; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=iHZb+t3N1v3cuDbkvMS9bRvchA+3PouRKjUPHYWGTfY=; b=jKvc6Pltj//5W/+xkGK067K4pjhRmtbtLQDYb5TO4FQgtXTkw65BYCPFYtd0rlBN0V uHpHGrpKy2dKVUwJw8+kS0MD8P77FXBoSYT2tkibv73TYF8SCjDuEPjWH6/toj3WeeK1 tmANPrbvm7i2x3T4TgiNeN7SD9Ppt14lasiHTt1RDbZdue+jjrrm7cS8v+2l666B/DaA ELiQcgZAhVed7xhWVLkGVYLhbKrhEnd9yKStoJd5USWrOjCmv5LbUob4HM/KUaVDCkXn wHmSTaL/w5wvsPdo9xZvUPmdjfBna1eZd2SNPjunyeQe8piJP/Z51PhHz1tICDQdrUJw 5R9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=iHZb+t3N1v3cuDbkvMS9bRvchA+3PouRKjUPHYWGTfY=; b=XAhFGjFhdE2enV6+UUPaaMmTs2tl42LWy0UyNETh4JdssyML+36s111r5BGjespQu5 npzKvt0IWmcwGSq1U4eGODA4qSHKd779K1fFU+JVVqlQYYYCLfiIxQi51h7LVB6slL/h lxq7BoswKPCUJYfnRd6FctsULY+BuMjfYZQoK2v0z1985qXg8MHLQlE25UgOnSoM8cgl UZtXWKujLQFKTWbbR26sOdn17eimM2UkailIWeT7YY3hbvRLRmvr2/cRmF1pT2ADOgpd s6i33LgXD/CB2PlN4H+aSHKXfxmbQn/PhOtbVCOpOitPGPxA59ws2DX9EK9dHirytZ5l Fdvw== X-Gm-Message-State: ABuFfogzKLNV350b0fSR0oQgWArJZxLnbubJrkoIXUH3B8UcwhWQnBIN ao23Qj4W58IKCECQbWf9GbeDvQ== X-Google-Smtp-Source: ACcGV63D/OMn4lrUqmwKFxitaP2PGvgrHp328ryAYtfZ+9X8UMMdy+nIfQHNKXXJMKyEAP/z4Kk2vA== X-Received: by 2002:a19:169e:: with SMTP id 30-v6mr62316lfw.9.1539089873224; Tue, 09 Oct 2018 05:57:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a2e:9797:: with SMTP id y23-v6ls188874lji.27.gmail; Tue, 09 Oct 2018 05:57:52 -0700 (PDT) X-Received: by 2002:a2e:5109:: with SMTP id f9-v6mr17633079ljb.155.1539089872189; Tue, 09 Oct 2018 05:57:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539089872; cv=none; d=google.com; s=arc-20160816; b=C7gf5iZhh0wh6FZehALiahY/1DXIcMdu1GtL3JzDPXYJ0Duk4y/5AcOmkwV+opVXqn hgaA4aaBnPbq/Ghdd3zcv6s0DtL8sANCYV3qtBfaPBGVtRfgRu0aizQ4BwN11eZiBWHw AdRPqo6uofYmXNtLMTalmT7IfICE5zU54ceen2fA8gMlIr7HS3w3xKemhOB7jSHbUVFL igpucxSnvwOW7/ZJonYX924sFVXluIdN9itnscjxr5YJ4kTCdtldKkGzxykqdy21Fn7X qJVGPFhj5OxEdu9Nz8TW7bKSVUENX4qB1g9UOdIoTnv4sXEjhBhp182xmHrIq1JTfMXx YZMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4+LsnQ67Jf43MdzW+pEZh8wB0abKNxhxF3pcyqXjRqw=; b=Vi3AwEp3JDvB1AWjiYv+KKrl7IngumkyAJuBjiBtkTnGpMFrM6tkcv6sRAbsed7fSr jCzGLSCYglEGc49avxl8g3k4zGkI5bylVF+AgVhsIa93XGeY8LqwPBzScBEChH0qJ/FW Njg6DlpDwuXwYskjQm3Euy1Lqqhflh7FJ5Z0JTjHOL7OfNtMuwtkPBxU3G1bomGbDaOX 23N30tOqlHOU0dwzDpZ7fT8HwvoUAeP9KzeciSius3hNWqXyd4ZGkhOe1HF1VzrYSbyS T0n7TjO5waa2oQm/EBY8/spf5y/sYrOxOjgsFQpeXgcTPhmFwU0RMeJ1JayvWLXPgcPE aMgA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KodgwLwb; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id r63-v6sor6013439lfi.3.2018.10.09.05.57.52 for (Google Transport Security); Tue, 09 Oct 2018 05:57:52 -0700 (PDT) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a19:df43:: with SMTP id q3-v6mr14893669lfj.53.1539089871431; Tue, 09 Oct 2018 05:57:51 -0700 (PDT) In-Reply-To: X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KodgwLwb; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40436 Archived-At: --000000000000106e8f0577cb49f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Top posting intentional) I will wrote a detailed case ofnthe issue once I research the security issue (and try to write an exploit as a PoC) before any language proposal. At language proposal I will start over a new thread because it should cover value tainting and containers (both user defined and standard). For example std::vector with or without specially fitted destructors. I will not engange in any further discussion until I understand the broader situation I referred to. I think that this should involve type strongness since a function my pass a sensitive function to a callee, and the "sensitiveness" of data should be propagated for any operations the callee may do. I already experienced this before when using C's FILE* where the io library caches data internally forcing me to call setbuff(nullptr) (didn't experiment with the C++'s streaming library yet). Again, thanks for all the useful feedback. I don't want to spam more people and want to "stop and think" quietly :) It even leads to a security conference paper. El mar., 9 oct. 2018 9:42, Miguel Ojeda escribi=C3=B3: > Hi Florian, > > On Tue, Oct 9, 2018 at 2:24 PM wrote: > > > > For your second point, I didn't think about it yet. So I didn't take it > into consideration when I proposed the [[undead]] attribute. But if your > goal is security, then you would also need to take into consideration thi= s. > > Let's imagine an attribute [[secret]]. > > Every object marked as [[secret]] will be cleaned before function exit. > > This cleaning means set to zero every location that still contains the > object (known to the compiler). > > This sounds very similar to secure_val, but as a variable attribute. > > > Also, in order to not deduce the secret from other temporaries, any > value depending on a [[secret]] object is also marked implicitly as > [[secret]]. > > > > This does not address cache persistency, but it can be covered if the > [[secret]] can take an optional argument to ensure cache lines related to > this object are flushed (done by the compiler). > > > > With this, you start to have a pretty strong security plan for stack > objects. But the heap objects cannot be marked as secret. So for that, > maybe you could mark the delete statement as [[secret]] and let the > compiler do the same thing for heap objects. > > I would say users should not care where or how the value is stored. > Having to mark delete statements with an attribute seems odd. As a > user, I would simply prefer to be able to mark my type T with > [[secret]] and then *that* could be put into the heap. That is the > reason I went for a template, because it looked natural to wrap values > with it: > > std::secure_val my_very_secret_number; > std::secure_val my_private_key; > > etc. > > > And also, a [[secret]] reference would need mark every dependant object= s > as [[secret]], but the referenced object itself would not be cleaned. > > Here I'm just throwing ideas into the wild, but I think you get the ide= a. > > > > All in all, I think it is possible to improve security with such > attributes, but I don't think an attribute on statements is the right way= .. > > > > Indeed, I think a better idea is to work on the storage side, not on > the statement level. > > Cheers, > Miguel > > -- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kBPp9= uONTPvC7L9n8%2BrtnXtE12MM_YJQDw1JsbVQ9frA%40mail.gmail.com > . > --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CAFdMc-2oUcYW6CrwESORd4JF8qvKNxABtweWb_nSei5xoMd= K%3DA%40mail.gmail.com. --000000000000106e8f0577cb49f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Top posting intentional)

I will wrote a detailed case ofnthe issue once I research the= security issue (and try to write an exploit as a PoC) before any language = proposal.

At language pr= oposal I will start over a new thread because it should cover value taintin= g and containers (both user defined and standard).
F= or example
=C2=A0 =C2=A0std::vector<std::string&g= t;
with or without specially fitted destructors.
I will not engange in any further discussion until I un= derstand the broader situation I referred to.
I thin= k that this should involve type strongness since a function my pass a sensi= tive function to a callee, and the "sensitiveness" of data should= be propagated for any operations the callee may do.
I already experienced this before when using C's FILE* where the io li= brary caches data internally forcing me to call setbuff(nullptr) (didn'= t experiment with the C++'s streaming library yet).

Again, thanks for all the useful feedback. = I don't want to spam more people and want to "stop and think"= quietly :)

It even lead= s to a security conference paper.

El mar., 9 oct. 2018 9:42, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com&g= t; escribi=C3=B3:
Hi Florian,

On Tue, Oct 9, 2018 at 2:24 PM <florian.csdt@gmail.com> wrote= :
>
> For your second point, I didn't think about it yet. So I didn'= t take it into consideration when I proposed the [[undead]] attribute. But = if your goal is security, then you would also need to take into considerati= on this.
> Let's imagine an attribute [[secret]].
> Every object marked as [[secret]] will be cleaned before function exit= ..
> This cleaning means set to zero every location that still contains the= object (known to the compiler).

This sounds very similar to secure_val, but as a variable attribute.

> Also, in order to not deduce the secret from other temporaries, any va= lue depending on a [[secret]] object is also marked implicitly as [[secret]= ].
>
> This does not address cache persistency, but it can be covered if the = [[secret]] can take an optional argument to ensure cache lines related to t= his object are flushed (done by the compiler).
>
> With this, you start to have a pretty strong security plan for stack o= bjects. But the heap objects cannot be marked as secret. So for that, maybe= you could mark the delete statement as [[secret]] and let the compiler do = the same thing for heap objects.

I would say users should not care where or how the value is stored.
Having to mark delete statements with an attribute seems odd. As a
user, I would simply prefer to be able to mark my type T with
[[secret]] and then *that* could be put into the heap. That is the
reason I went for a template, because it looked natural to wrap values
with it:

=C2=A0 std::secure_val<int> my_very_secret_number;
=C2=A0 std::secure_val<char [N]> my_private_key;

etc.

> And also, a [[secret]] reference would need mark every dependant objec= ts as [[secret]], but the referenced object itself would not be cleaned. > Here I'm just throwing ideas into the wild, but I think you get th= e idea.
>
> All in all, I think it is possible to improve security with such attri= butes, but I don't think an attribute on statements is the right way. >

Indeed, I think a better idea is to work on the storage side, not on
the statement level.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq7= 2kBPp9uONTPvC7L9n8%2BrtnXtE12MM_YJQDw1JsbVQ9frA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2oUcYW6C= rwESORd4JF8qvKNxABtweWb_nSei5xoMdK%3DA%40mail.gmail.com.
--000000000000106e8f0577cb49f2-- .