==================================================================== CERT-Renater Note d'Information No. 2021/VULN314 _____________________________________________________________________ DATE : 10/06/2021 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-372.html https://xenbits.xen.org/xsa/advisory-373.html https://xenbits.xen.org/xsa/advisory-374.html https://xenbits.xen.org/xsa/advisory-375.html https://xenbits.xen.org/xsa/advisory-377.html _____________________________________________________________________ Xen Security Advisory CVE-2021-28693 / XSA-372 version 3 xen/arm: Boot modules are not scrubbed UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The bootloader will load boot modules (e.g. kernel, initramfs...) in a temporary area before they are copied by Xen to each domain memory. To ensure sensitive data is not leaked from the modules, Xen must "scrub" them before handing the page over to the allocator. Unfortunately, it was discovered that modules will not be scrubbed on Arm. IMPACT ====== Sensitive information from the boot modules might be visible to another domain after boot. VULNERABLE SYSTEMS ================== Only Arm systems are vulnerable. System running with "bootscrub=off" (disabling boot scrubbing) are not vulnerable. All versions of Xen since 4.12 are vulnerable. MITIGATION ========== There is no mitigation available. CREDITS ======= This issue was discovered by Julien Grall of Amazon. RESOLUTION ========== Applying the appropriate set of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa372/*.patch xen-unstable xsa372-4.15/*.patch Xen 4.15.x xsa372-4.14/*.patch Xen 4.14.x - Xen 4.13.x xsa372-4.12/*.patch Xen 4.12.x $ sha256sum xsa372* xsa372*/* 06e43684c2d8a3085d55b8b40f57e1b9f1ee47519fac844dcbc21b57fb039915 xsa372.meta 8f872c7abe6c795dbef2e401f2223fda0dbb9d7c57dfebd8047eef37e1caf952 xsa372-4.12/0001-xen-arm-Create-dom0less-domUs-earlier.patch a43c6c11481cc3f13900908cee79cc6c5401921f6f4e8858c0796cf301cfe923 xsa372-4.12/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch 6d1fad53795ebd251520022b6be901215426ba78ccbbc075841698973b74d2a2 xsa372-4.14/0001-xen-arm-Create-dom0less-domUs-earlier.patch 2ceb5d4d8d4f8a18046721daa3bb29633a620c4794b54e1265f5d4d69a314c3b xsa372-4.14/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch 7feae5f9f7f2df0ec38c0b9358dc32671a9955f966b3120e17bb3fd820ce33ff xsa372-4.15/0001-xen-arm-Create-dom0less-domUs-earlier.patch 0cc73b4751fa49f68c6584b1c7882606c6e1f18561d8a6547017ab068de4eb4b xsa372-4.15/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch 950672405c695ebf6ae59eebeb454bc0738b7afc3efa35ef9680d76eef4d4ec0 xsa372/0001-xen-arm-Create-dom0less-domUs-earlier.patch 9ceccd39c795e7756052a2f00256e043c8dda42e2c691df30e3f8b59190d6e8e xsa372/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2021-28692 / XSA-373 version 2 inappropriate x86 IOMMU timeout detection / handling UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= IOMMUs process commands issued to them in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. The course of action upon a perceived timeout actually being detected is inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue as if the IOMMU operation succeeded. IMPACT ====== A malicious guest may be able to elevate its privileges to that of the host, cause host or guest Denial of Service (DoS), or cause information leaks. VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been inspected. Only x86 systems with in-use IOMMU hardware are vulnerable. x86 systems without any IOMMUs in use are not vulnerable. On Arm systems IOMMU / SMMU use is not security supported. Only x86 guests which have physical devices passed through to them can leverage the vulnerability. MITIGATION ========== Not passing through physical devices to untrusted guests will avoid the vulnerability. CREDITS ======= This issue was discovered by Igor Druzhinin and Andrew Cooper of Citrix, and further issues were uncovered by by Jan Beulich of SUSE while trying to fix the first issue. RESOLUTION ========== Applying the appropriate set of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa373/xsa373-?.patch xen-unstable xsa373/xsa373-4.15-?.patch Xen 4.15.x xsa373/xsa373-4.14-?.patch Xen 4.14.x xsa373/xsa373-4.13-?.patch Xen 4.13.x xsa373/xsa373-4.12-?.patch Xen 4.12.x xsa373/xsa373-4.11-?.patch Xen 4.11.x $ sha256sum xsa373* xsa373*/* 2ded01092088735e0d8a0e378a41b772ec0f17ceb7afabc78228670c43407fc2 xsa373.meta f62df56cd176237521aa2ed4a22b0e893318b85bb0ce3c17bd7fca5282b6105b xsa373/xsa373-1.patch 9eed9566508e116c4da6c201b36fe7e53e98f2daf96cce8ed0a9ca192d783edc xsa373/xsa373-2.patch ffee9d17e40798c053a67707dd13d7a944e4a53de7bcfe3e146eac7871ca2608 xsa373/xsa373-3.patch c51bea462222c090ae671f14471ece00724348e6c04e5850f9b91d0b1eceaad8 xsa373/xsa373-4.11-1.patch 9a3b331e404a38c72ec154cefd78f1f67db6f25dcc1bd554b37ff50899ea42ff xsa373/xsa373-4.11-2.patch dba77bce4e6c88ec43df61e88bd5c8bee6e32c0ff681cbeddc4bceb0ee6c73dd xsa373/xsa373-4.11-3.patch b1f14e8885e3004de79c5012a1d9278d7a0c39633c5b73cbfda28679f1722c38 xsa373/xsa373-4.11-4.patch 791bccec1e7ba4429a0bafef5fd5a35a68562cee333d0962c70477172493ef3b xsa373/xsa373-4.11-5.patch cc4e1bcef148dbfc94ada92bef4408c5516cff2cf249e43c5595b1dbffbbc1e4 xsa373/xsa373-4.12-1.patch 12ffdac1526d96c4f1b572360a7f1a0371e8a177cf15228b126c1032de4e8930 xsa373/xsa373-4.12-2.patch 619425ba44f449bf7b0f519040ee579adff0d0293a95e9b0f70c943c02ae22fb xsa373/xsa373-4.12-3.patch b1f14e8885e3004de79c5012a1d9278d7a0c39633c5b73cbfda28679f1722c38 xsa373/xsa373-4.12-4.patch 96b3dd11d38ca8ca0b2dfe2dfb571045fcda78dbfe416580c9b04c5a8ce5fcef xsa373/xsa373-4.12-5.patch 4add1d05ad2780904ebc89b4d1a93a8f2757b6e9f45b075afce46392ae406b58 xsa373/xsa373-4.13-1.patch b064324db709078b8ef479df0c31ff3391a506755bfb0186d7d165592d025357 xsa373/xsa373-4.13-2.patch 6fe47fbba0c9d86f48643182d8a7c64ff70a7c8b290b0e93afe1d43d04bed480 xsa373/xsa373-4.13-3.patch b1f14e8885e3004de79c5012a1d9278d7a0c39633c5b73cbfda28679f1722c38 xsa373/xsa373-4.13-4.patch 96b3dd11d38ca8ca0b2dfe2dfb571045fcda78dbfe416580c9b04c5a8ce5fcef xsa373/xsa373-4.13-5.patch 4add1d05ad2780904ebc89b4d1a93a8f2757b6e9f45b075afce46392ae406b58 xsa373/xsa373-4.14-1.patch 8e61b7dda9ea21a830454e629fd23e3379b73fb230bd04107618e45975e117d1 xsa373/xsa373-4.14-2.patch a5aa80d8e893c268f171a5e429bfef0c553522f860e3e5132b4bd87d3a73c6b7 xsa373/xsa373-4.14-3.patch 25bfd2b821ae2cc867b8e2d480528ebd435da76cfab766e8106573cf8dc6f36c xsa373/xsa373-4.14-4.patch 162b3f14d15fe5ca2cb659efad6635f3803dde6fa97a6f0f1f7f202d3ea72d94 xsa373/xsa373-4.14-5.patch 4add1d05ad2780904ebc89b4d1a93a8f2757b6e9f45b075afce46392ae406b58 xsa373/xsa373-4.15-1.patch 9eed9566508e116c4da6c201b36fe7e53e98f2daf96cce8ed0a9ca192d783edc xsa373/xsa373-4.15-2.patch 13642541b056ed47129d8143a919bcc81a73797baedc3bd90afeb33f021e6d31 xsa373/xsa373-4.15-3.patch b2517a7e92c26a818e94ed5133d5aef6ef1d3a7a98f2f5355f1ad6f30baa3ab9 xsa373/xsa373-4.15-4.patch 3ca056796b93cb07ddb7e1dfda98410162382fc56135eb08bc5ff19137d8c427 xsa373/xsa373-4.15-5.patch b2517a7e92c26a818e94ed5133d5aef6ef1d3a7a98f2f5355f1ad6f30baa3ab9 xsa373/xsa373-4.patch 0b7bb146330f7fdc7c8c331a618307819073654a13d9fe1d0a8b83ab037ae802 xsa373/xsa373-5.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2021-28691 / XSA-374 version 2 Guest triggered use-after-free in Linux xen-netback UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= A malicious or buggy network PV frontend can force Linux netback to disable the interface and terminate the receive kernel thread associated with queue 0 in response to the frontend sending a malformed packet. Such kernel thread termination will lead to a use-after-free in Linux netback when the backend is destroyed, as the kernel thread associated with queue 0 will have already exited and thus the call to kthread_stop will be performed against a stale pointer. IMPACT ====== A malicious or buggy frontend driver can trigger a dom0 crash. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== Systems using Linux version 5.5 or newer are vulnerable. MITIGATION ========== On x86 running only HVM guests with emulated network cards will avoid the issue. There's however no option in the upstream toolstack to offer only emulated network cards to guests. CREDITS ======= This issue was discovered by Michael Brown of iPXE and diagnosed by Olivier Benjamin, Michael Kurth and Martin Mazein of AWS. RESOLUTION ========== Applying the attached patch resolves this issue. xsa374-linux.patch Linux 5.5.0 - 5.12.2 $ sha256sum xsa374* 156cee65022359a5901cce97714d2abb16fef786246b1c4bf509083d21e085d6 xsa374-linux.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Deployment of the mitigation to disable PV network interfaces is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2021-28691 / XSA-374 version 2 Guest triggered use-after-free in Linux xen-netback UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= A malicious or buggy network PV frontend can force Linux netback to disable the interface and terminate the receive kernel thread associated with queue 0 in response to the frontend sending a malformed packet. Such kernel thread termination will lead to a use-after-free in Linux netback when the backend is destroyed, as the kernel thread associated with queue 0 will have already exited and thus the call to kthread_stop will be performed against a stale pointer. IMPACT ====== A malicious or buggy frontend driver can trigger a dom0 crash. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== Systems using Linux version 5.5 or newer are vulnerable. MITIGATION ========== On x86 running only HVM guests with emulated network cards will avoid the issue. There's however no option in the upstream toolstack to offer only emulated network cards to guests. CREDITS ======= This issue was discovered by Michael Brown of iPXE and diagnosed by Olivier Benjamin, Michael Kurth and Martin Mazein of AWS. RESOLUTION ========== Applying the attached patch resolves this issue. xsa374-linux.patch Linux 5.5.0 - 5.12.2 $ sha256sum xsa374* 156cee65022359a5901cce97714d2abb16fef786246b1c4bf509083d21e085d6 xsa374-linux.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Deployment of the mitigation to disable PV network interfaces is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2021-0089,CVE-2021-26313 / XSA-375 version 4 Speculative Code Store Bypass UPDATES IN VERSION 4 ==================== Correct the link to the AMD bulletin. ISSUE DESCRIPTION ================= Modern superscalar processors may employ sophisticated decoding and caching of the instruction stream to improve performance. However, a consequence is that self-modifying code updates may not take effect instantly. Whatever the architectural guarantees, some CPUs have microarchitectural behaviour whereby the stale instruction stream may be speculatively decoded and executed. Speculation of this form can suffer from type confusion in registers, and potentially leak data. For more details, see: https://www.vusec.net/projects/fpvi-scsb https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1003 https://software.intel.com/content/www/us/en/develop/articles/software-security-guidance/advisory-guidance/speculative-code-store-bypass.html https://software.intel.com/content/www/us/en/develop/articles/software-security-guidance/advisory-guidance/floating-point-value-injection.html https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#scsb https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#fvpi IMPACT ====== In attacker might be able to infer the contents of arbitrary host memory, including memory assigned to other guests. VULNERABLE SYSTEMS ================== Systems running all versions of Xen are affected. Whether a CPU is potentially vulnerable depends on its microarchitecture. Consult your hardware vendor. Xen running on ARM does not have runtime self-modying code, so is believed to be not vulnerable, irrespective of any hardware susceptibility. Xen running on x86 does have runtime self-modying code as part of emulation, and is believed to be potentially vulnerable. Xen is not vulnerable if retpoline or lfence mitigations for Spectre v2 protection are active. Protections depend on compiler support (as indicated by INDIRECT_THUNK), and a runtime setting (BTI-Thunk): # xl dmesg | grep -e INDIRECT_THUNK -e BTI-Thunk (XEN) Compiled-in support: INDIRECT_THUNK SHADOW_PAGING (XEN) Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS+ SSBD-, Other: SRB_LOCK+ IBPB L1D_FLUSH VERW BRANCH_HARDEN BTI-Thunk as either RETPOLINE or LFENCE prevents the vulnerability. MITIGATION ========== If Spectre v2 support is compiled in, but JMP is used by default, RETPOLINE or LFENCE can be selected with `spec-ctrl=bti-thunk=retpoline` or `spec-ctrl=bti-thunk=lfence`. CREDITS ======= This issue was discovered by Enrico Barberis, Hany Ragab, Herbert Bos, and Cristiano Giuffrida from the VUSec group at VU Amsterdam. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. Note that in 4.13 and newer the patch will only take effect when the SPECULATIVE_HARDEN_BRANCH hypervisor config option is enabled. 4.12 and older do not have such an option, and the change will take effect unconditionally. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa375.patch xen-unstable - 4.14.x xsa375-4.13.patch Xen 4.13.x xsa375-4.12.patch Xen 4.12.x - 4.11.x $ sha256sum xsa375* 367d5bb97c942b9f744a57645df87148772c0879de6f351f36f88147f3958e83 xsa375.meta 301ef80da837bc2af36a0958f35f42f4d267b20ec6e91ae5faf2616167ef49f8 xsa375.patch dc024daf17242b6477a16a349754a94b2b25cbbfd8c14475741b778710a44c93 xsa375-4.12.patch f70511d843c6617b932da11ffe857e2e3aa3834ccff07d4d0beba90d63a3dae2 xsa375-4.13.patch $ NOTE CONCERNING CVE-2021-0086 / CVE-2021-26314 ============================================== Floating Point Value Injection (FPVI) was discovered and disclosed in the same research as SCSB. Xen on x86 does in some cases emulate floating point operations with guest provided inputs, but does not have subsequent control flow dependent on results, transient or otherwise, of the operation. Therefore, we believe Xen is not vulnerable to FPVI, irrespective of any hardware susceptibility. NOTE CONCERNING MULTIPLE CVES ============================= Intel and AMD allocated different CVEs for SCSB and FPVI. We have included both on this advisory. The allocations are as follows: Issue | Intel | AMD ------+---------------+--------------- SCSB | CVE-2021-0089 | CVE-2021-26313 FPVI | CVE-2021-0086 | CVE-2021-26314 DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2021-28690 / XSA-377 version 2 x86: TSX Async Abort protections not restored after S3 UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= This issue relates to the TSX Async Abort speculative security vulnerability. Please see https://xenbits.xen.org/xsa/advisory-305.html for details. Mitigating TAA by disabling TSX (the default and preferred option) requires selecting a non-default setting in MSR_TSX_CTRL. This setting isn't restored after S3 suspend. IMPACT ====== After using S3 suspend at least once, CPU0 remains vulnerable to TAA. This is an information leak. For full details of the impact, see XSA-305. VULNERABLE SYSTEMS ================== See XSA-305 for details of susceptibility to TAA. Only systems which are susceptible to TAA and have the XSA-305 fix are vulnerable. Only systems which support S3 suspend/resume are vulnerable. The vulnerability is only exposed if S3 suspend/resume is used. MITIGATION ========== Not using S3 suspend/resume avoids the vulnerability. CREDITS ======= This issue was discovered by Andrew Cooper of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa377.patch xen-unstable - Xen 4.13.x xsa377-4.12.patch Xen 4.12.x xsa377-4.11.patch Xen 4.11.x $ sha256sum xsa377* 532cb030f97d72e8e534ad97182cd5e3aa0efeef405e255bb49649b4f0dd9947 xsa377.meta 21a30dbf80f6e78057cc7e785c8fda475d5a8a0b6b9442af3bd8ca31dd69becf xsa377.patch 3279317d56e7b8d0a2b0152b64b4c577381b8b01fa0a1a21ec6f855bb964278a xsa377-4.11.patch 65f61f1cb7bb0e068fd32e40755b9a9aae464d15ccd42c94dae68e495c5a45e0 xsa377-4.12.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================